Snelheid is bruikbaarheid.
Om het nauwkeuriger te zeggen, website-snelheid is een belangrijk onderdeel van bruikbaarheid. De meest intuïtieve interface ooit gemaakt door de geest van de mens zal je geen goed doen als de gebruiker wordt gepijpt tegen de tijd dat hij laadt.
Dat is het. Het artikel is klaar ... Ok, dus er is eigenlijk nog veel meer, maar die eerste zin is ongeveer de helft van wat je moet weten. We moeten onze websites snel maken.
Ik zou veel overtreffende trapuitdrukkingen zoals "laaiend snel" of "extreem snel", of zelfs "sneller dan een snel rijdend kogel" kunnen gebruiken, maar ze zouden ontoereikend zijn. Het is eenvoudiger om te zeggen dat er niet zoiets is als "te snel".
We moeten wel even nadenken over wat voor soort snelheid ik bedoel. Kortom, alle snelheid. Meer specifiek, drie soorten snelheden:
Dit is de tijd die nodig is om alle informatie naar de apparaten van uw gebruikers te downloaden. Dit wordt vooral beïnvloed door de snelheid van de internetverbinding en de werkelijke grootte van de bestanden.
Je kunt niet veel aan de verbinding doen, maar je kunt veel aan de bestandsgrootte doen.
Nadat uw bestanden zijn gedownload, moeten ze worden verwerkt en weergegeven door de browser. Al die verwerking en weergave wordt beïnvloed door de manier waarop uw code is geschreven en al het andere dat op de telefoon, tablet of laptop / desktop van de gebruiker wordt uitgevoerd.
Het enige dat je kunt regelen, is je eigen code, maar dat maakt een groot verschil.
En dan is er de psychologische factor. Snelle websites kunnen eruit zien en aanvoelen alsof ze langzaam gaan. Langzame websites kunnen een klein beetje sneller worden gemaakt met de juridische toepassing van enkele trucjes.
Dit deel gaat over het bestuderen van je gebruiker en hen laten weten wat er gaande is wanneer ze communiceren met je website of app.
U moet aandacht besteden aan alle drie aspecten van de snelheid van websites om uw site het gevoel te geven dat het snel gaat. En hoe groter de site, hoe meer er te optimaliseren is.
Laten we beginnen.
Vele malen, vooral op die kleinere, experimentele projecten waar ik zo dol op ben, merk ik dat ik meer tijd aan de CSS besteed dan aan enig ander deel van de code. Vaak is er ook meer CSS geschreven dan HTML of JavaScript. Dat is dus een indicatie voor hoeveel uw CSS de bestandsgrootte kan beïnvloeden.
Dan is er natuurlijk nog de vraag hoe snel uw website daadwerkelijk op de desktop, laptop, tablet of telefoon van uw gebruiker wordt uitgevoerd. Veel van het daadwerkelijke "werk" of het renderen van een webpagina wordt gedaan door de software, met een beetje hulp van je GPU.
Het laadt mogelijk snel, maar scroll langzaam. De manier waarop uw CSS is geschreven, heeft een direct effect op hoe snel een bepaald apparaat in staat is om de webpagina daadwerkelijk weer te geven nadat de bestanden zijn gedownload.
Bij het optimaliseren van een website om sneller te werken, is de CSS meestal een goede plaats om te beginnen.
CSS die zich in uw stylesheet bevindt en niets doet, maakt uw bestanden onnodig groter. Oké, dus deze lijkt misschien een goed idee; maar het gebeurt nog steeds met de besten van ons.
Je neemt wat content weg en vergeet de oude CSS te verwijderen. U wijzigt de klasse of ID van een containerelement en vergeet de oude CSS te verwijderen. Je schrijft CSS, beseft dat er een betere manier is, en vergeet ... je snapt het.
Gooi meerdere front-end ontwikkelaars in de mix en je hebt een recept voor een log, onhandelbaar stylesheet of een verzameling ervan, als je niet voorzichtig bent. Ongebruikte code vertraagt het laden van de pagina vanwege zijn bestaan als gegevens. Het vertraagt de ontwikkeling omdat het mensen die het stylesheet lezen, kan verwarren.
Het kan ook betekenen dat de renderingstijden langzamer zijn, omdat het gewoon meer CSS is om door de browser te laten kijken terwijl het overeenkomt met alle CSS naar de juiste HTML-elementen.
Of u nu alle oude CSS handmatig controleert en verwijdert, gebruikt u geautomatiseerde hulpmiddelen om ongebruikte CSS-kiezers te vinden of verwijdert u dingen willekeurig totdat iets kapot gaat (doe dat niet), dan moet u die oude code verwijderen.
Spreken over hoe de browser overeenkomt met de CSS met de juiste HTML, is het tijd om te kijken naar CSS selectors. Er is veel geschreven over welke selectors het snelst renderen, welke langzaam zijn, of je de moeite moet nemen met de langzame, enzovoort.
Het probleem is dat veel van deze informatie oud is. In het jaar 2000 schreef Dave Hyatt (een ontwikkelaar die aan Safari werkte en een actief lid was van de CSS-werkgroep van W3C):
De trieste waarheid over CSS3-kiezers is dat ze helemaal niet zouden moeten worden gebruikt als je de prestaties van de pagina belangrijk vindt.
Als je een kijkje neemt het document dat citaat kwam van, je zult zien dat hij sprak over selectors zoals : first-child en andere pseudo-selectors. En hij had gelijk.
Hij is nog steeds; maar in de afgelopen vijftien jaar zijn computers een beetje gevorderd. Tegenwoordig moet de extra inspanning die de computer nodig heeft om die CSS weer te geven niet door iedereen opgemerkt worden, behalve degene die de goedkoopste goedkope mobiele apparaten gebruiken.
Dat is een probleem op zich, dus echt, het zal afhangen van het project bij de hand, de demografische gegevens van uw doelgroep, enzovoort. Simpel gezegd, gebruik je gezond verstand, en misschien overboord gaan op de pseudo-selectors.
Anders, tenzij uw pagina's de lengte van een boek bereiken, hebben de selectors die u gebruikt weinig effect op de prestaties van uw site. Bekijk toch het document hierboven gelinkt en leer wat het snelst is en wat niet. Mogelijk vindt u de informatie nog steeds nuttig.
Je kunt ook zien Dit artikel van CSS-Tricks voor een iets recentere kijk op het onderwerp.
Natuurlijk zijn er ook CSS-eigenschappen die meer tijd nodig hebben om te renderen dan andere. De klassieke eigenschappen zoals breedte, hoogte en kleur zijn nog steeds de snelste. Degenen die de neiging hebben om iets langer te duren (en kunnen variëren van browser tot browser) zijn meestal CSS3-eigenschappen zoals box-shadow.
Het proces van het toevoegen van een slagschaduw aan een element is complex, wat betreft het renderen van webpagina's. Wat interessant is om op te merken is dat, zoals opgemerkt HTML5 Rocks , de vereiste verwerkingskracht kan sterk variëren, afhankelijk van de specifieke afmetingen van de slagschaduw.
Dit artikel geeft aan dat hetzelfde geldt voor andere eigenschappen zoals grensradius en transformatie.
Nogmaals, deze zouden weinig effect hebben op de weergave van een pagina op uw gemiddelde desktop of laptop. Mobiele apparaten kunnen echter een grotere hit worden, en de ervaring zou daardoor kunnen lijden. Iedereen heeft een hekel aan schokkerig scrollen.
Toch moet dat worden afgewogen tegen de kosten van het gebruik van afbeeldingen om dezelfde effecten te produceren. Iedereen herinnert zich de dingen die we deden om keer op keer afgeronde hoeken te krijgen?
Ga gewoon niet overboord en je stijlen moeten snel genoeg worden weergegeven.
Nu komen we op een ander terrein. CSS-animaties kunnen razendsnel zijn of ze kunnen de browser vertragen tot het punt dat game-platforms moeite hebben om bij te blijven.
Dit komt gedeeltelijk omdat niet alle animatie gelijk wordt weergegeven. Een deel van het zware werk wordt gedaan door de hardware, terwijl andere soorten animatie volledig door de eigen functies van de browser moeten worden gerenderd. Dit is vooral duur op mobiele apparaten.
In een ander artikel op HTML5 Rocks zijn de CSS-eigenschappen die het snelst te animeren zijn positie , schaal , rotatie en dekking.
Bekijk het artikel voor een completer overzicht van wat kan worden geanimeerd terwijl de "kosten" laag blijven.
Hier bied ik je het meest praktische advies dat ik, de auteur, kan geven. Gebruik CSS-preprocessors zoals LESS, SASS en Stylus. Natuurlijk, als u ze verkeerd gebruikt, kunt u grotere stylesheets genereren dan u had bedoeld; maar de potentiële voordelen zijn het waard.
Als u bijvoorbeeld het aantal HTTP-verzoeken aan de server wilt verminderen (altijd een goed idee), neemt u alle resets en frameworks op in één LESS / SASS-bestand. Wanneer het compileert, bevindt het zich allemaal in een enkel stylesheet. Bovendien bieden de meeste preprocessors de mogelijkheid om alle CSS in verkleinde vorm uit te voeren.
Op deze manier kunt u zoveel verschillende bestanden gebruiken als nodig voor het organiseren van code, zonder de bestandsgrootte onnodig te beïnvloeden.
JavaScript kan erg langzaam zijn. Om specifieker te zijn, JavaScript kan een veel directer effect hebben op het gedeelte "verwerking" van de snelheidsvergelijking dan de CSS. Erger nog, JS kan exponentieel zwaarder worden in termen van bestandsgrootte om schijnbaar triviale dingen te bereiken.
Het is een dubbele whammy van pijnlijke traagheid, en onze gebruikers zijn vaak de slachtoffers, vooral die in mobiele browsers. Dit is echter niet de schuld van de taal. Hoe verrekte onze JS komt, staat vaak in directe verhouding tot onze onwetendheid over programmeren in het algemeen.
Ik ben een niet-ontwikkelaar. Ik heb vaak bibliotheken zoals jQuery of individuele, stand-alone JS-plug-ins gebruikt om dingen gedaan te krijgen. Hoe meer ik moet doen, hoe meer plug-ins ik nodig heb om alles te laten werken. Deze plug-ins en frameworks worden geleverd met extra opties en functies die ik misschien nooit zal gebruiken.
Er is de bandbreedte-stelen bloat, daar.
Bovendien werken plug-ins mogelijk niet goed samen. Ze kunnen elkaar vertragen, anders zou iemand kunnen stoppen om helemaal te werken.
Daar is de verspilde verwerkingskracht.
Als je echt je website wilt versnellen, milliseconden wilt scheren (of hele seconden, in sommige gevallen), dan is dit wat je moet doen:
Net als bij CSS is het het beste om JS in externe bestanden te bewaren en te koppelen aan uw HTML. Je denkt misschien niet dat het zo erg is als je niet veel JS-code hebt, en het voegt wel een HTTP-verzoek toe, maar hier is het volgende: externe CSS- en JS-bestanden worden in de cache opgeslagen door de browser.
Dus wanneer dezelfde pagina opnieuw wordt aangevraagd, of andere pagina's op uw site waarop dezelfde CSS of JS wordt aangevraagd, worden die externe bestanden in de cache gebruikt in plaats van opnieuw te worden gedownload. Dat is een snellere laadtijd van de site en een iets snellere verwerking. Het is de moeite waard om zo nu en dan extra te bellen naar de server.
Kort gezegd gaat de theorie als volgt: de browser geeft eerst wat er bovenaan de broncode staat van een pagina weer. Dat is de reden waarom dingen zoals de tag dichtbij komen.
JavaScript-bestanden kunnen echter alles vertragen door ervoor te zorgen dat de HTML-code van de browser pas wordt weergegeven als deze is geladen. Omdat de meeste veelgebruikte JS-effecten en plug-ins alleen moeten werken nadat de rest van de pagina op het scherm staat, is dit minder dan ideaal.
Verbeter de gebruikerservaring en verkort de waargenomen laadtijd door te linken naar die externe bestanden onderaan de pagina, vlak voor de tag.
Tegen de tijd dat een gebruiker aan de slag gaat om iets te doen dat JS nodig heeft, moet het klaar zijn om te gaan.
Als u een volledige app ontwerpt, kunt u deze sectie misschien negeren. Een goed, flexibel en licht raamwerk kan ontwikkelaars een enorme voorsprong geven. Voor kleine tot middelgrote websites kan echter een JavaScript-framework overkill zijn. Op deze websites wordt JS meestal gebruikt in de back-end van het CMS voor het beheren van inhoud. Aan de voorkant heeft u mogelijk een afbeeldingschuifregelaar of een metselwerklay-out of twee. Als je echt zin hebt, kun je automatisch aanvullen in de zoekbalk.
De meeste inhoud hoeft niet zo te worden verbeeld en geanimeerd als deze. JavaScript moet zoveel mogelijk worden gereserveerd om de gebruikerservaring te verbeteren. Als u erop vertrouwt om een site eenvoudig op te knappen, kan dit leiden tot een langzame, trage site, vooral op mobiele apparaten.
In zekere zin zijn alle codekaders allemaal hetzelfde, of het nu JavaScript, PHP, Python, HTML of CSS is: elke functie is een stel code. Wanneer je een framework of plug-in voor een job kiest, vraag jezelf dan af of je elke functie die het aanbiedt, of zelfs de meeste daarvan, gaat gebruiken.
Zo nee, is het framework modulair? Kun je alleen de onderdelen kiezen en kiezen die je echt nodig hebt? Als dat zo is, en je gelooft dat de grootte van de bestanden de moeite waard is, ga er dan voor! Anders is het een goede gewoonte om te zien wat u kunt uithalen, meer dan wat u kunt inpakken.
Niet permanent! Zie het zo, is er enige inhoud of functionaliteit op uw site verborgen door JS? Kunnen mensen er toegang toe krijgen zonder JS in hun browsers te hebben ingeschakeld?
Als dat zo is, dan geweldig. Als mensen echter geen belangrijke informatie kunnen zien, contact met u kunnen opnemen of zonder JavaScript correct kunnen navigeren, hebt u een probleem. Natuurlijk kun je erop vertrouwen dat de meeste mensen het nog steeds hebben ingeschakeld, maar je hebt altijd die edge-cases.
Hoe verhoudt dit zich tot de snelheid van websites? Stel je voor hoe traag browsen gaat krijgen als een deel van je website plotseling gewoon niet werkt.
Nee serieus, als je geen ontwikkelaar bent, en je hebt het budget voor één, ga er dan een halen, zelfs voor kleine, eenvoudige banen. Het is op de lange termijn goedkoper om een ervaren iemand in te huren om het goed te doen, één keer.
In het geval dat dingen vreselijk mis gaan (en we hebben het hier over computers, dus er zal iets fout gaan), zullen ze ontdekken wat er sneller fout is gegaan. Ze zullen ervaring hebben met het vinden van dergelijke problemen en deze oplossen. Als er niets anders is, zijn ze beter in het googlen van die specifieke onderwerpen.
Het belangrijkste is dat ze weten hoe ze moeten doen wat moet worden gedaan met minder code. Minder code (meestal) wordt sneller uitgevoerd en (altijd) sneller gedownload. Dat is het eenvoudigste advies dat ik kan geven.
(Als u een ontwikkelaar bent of aan het leren bent, heb ik een lijst met zelfstudies samengesteld die onderaan dit artikel zullen worden weergegeven. Inbegrepen zijn enkele beginnershandleidingen voor het schrijven van JavaScript dat snel wordt uitgevoerd.)
Wanneer je video uit de vergelijking haalt, is het grootste ding op een bepaalde inhoudgestuurde site de afbeeldingen. Afbeeldingen hebben de neiging groot, omvangrijk en langzaam te zijn als ze niet zijn geoptimaliseerd.
Nu de proliferatie van netvliesschermen ons dwingt grotere afbeeldingen te gebruiken als we willen dat de dingen er op elk apparaat goed uitzien, wordt het probleem niet eenvoudiger op te lossen. En erger nog, het is een kwestie die je gemakkelijk vergeet totdat je uiteindelijk meer uitgeeft dan bedoeld voor bandbreedte.
Wanneer elke byte telt, kunnen we het ons niet veroorloven om te vergeten.
Het goede nieuws is dat dit op geen enkele manier een nieuw probleem is. Waarom is dat goed? Het betekent dat er talloze mogelijke oplossingen zijn om uit te kiezen, en je kunt er meerdere tegelijk gebruiken. In feite is dat over het algemeen een goed idee.
Dus totdat ISP's en hostingbedrijven ons alle onbeperkte gratis bandbreedte gaan geven (houd je adem niet in), hier zijn enkele dingen die je kunt doen:
Simpel gezegd, doe visueel zoveel mogelijk met CSS en JavaScript voordat u naar afbeeldingen gaat. Code zal altijd goedkoper zijn om over te zetten dan afbeeldingen, dus blijf daar zoveel mogelijk bij. Ondanks de verwerkingskracht die wordt gebruikt door CSS-gebaseerde slagschaduwen, verlopen en dergelijke, kunt u de afwegingen overwegen.
Onthoud ook dat SVG-afbeeldingen in dit geval tellen als "code", want dat is alles: XML-code die wordt weergegeven als een afbeelding. Daarom moeten ze worden gebruikt wanneer u vectorgerelateerd iets nodig heeft.
Nu, terugkomend op die eerder genoemde netvliesschermen, wat doen we eraan? Hoe besparen we daar op bandbreedte?
Dit is waar we ons wenden tot het element en de eigenschap image-set . Ze zijn relatief nieuw en worden niet volledig ondersteund, maar ze stellen browsers wel in staat om de juiste afbeeldingsgrootte te kiezen voor het apparaat dat wordt gebruikt.
Dus hoewel dit u geen bandbreedte bespaart voor iemand die uw site in hun iMac bekijkt, is het niet zo belangrijk, omdat ze waarschijnlijk breedband hebben. Iemand die op zijn telefoon zit, krijgt intussen een kleinere versie van dezelfde afbeelding, waardoor deze niet te lang hoeft te wachten.
Veel problemen met de afbeeldingsgrootte worden opgelost zodra u weet welk beeldformaat in een bepaalde situatie moet worden gebruikt. Ik zou kunnen doorgaan over de specifieke afbeeldingsindelingen, hoe de compressie werkt, enzovoort, maar je hoeft eigenlijk maar een paar dingen te onthouden:
Dat is echt alles. Als u dit doet en met de optimalisatie-instellingen speelt wanneer u de afbeeldingen opslaat, kunt u vaak behoorlijk goede kwaliteit krijgen bij relatief kleine bestandsgroottes.
Er is echter een nieuwe indeling genaamd WebP, die automatisch wordt ondersteund door Chrome en Opera. Google vorderingen dat WebP-bestanden 26% kleiner zijn dan PNG's en 25-34% kleiner, afhankelijk van een aantal factoren.
Dit is goed nieuws, behalve twee dingen: Firefox en IE. Als u het niet erg vindt om fallbacks en een extra script te gebruiken, kunt u vandaag het WebP-formaat gebruiken. Gewoon downloaden WebPJS en je bent klaar om te gaan.
WebPJS gebruikt JavaScript en een beetje Flash ( zucht ... maar dat is alleen voor IE) om het te laten werken, maar het werkt. Je zou het kunnen overwegen als je snel veel en veel grotere afbeeldingen moet serveren, met als nadeel dat het zonder de JS niet zal werken.
Er zijn twee soorten compressie die u op uw afbeeldingen kunt gebruiken. Ten eerste hebben we lossy-compressie . Dit wordt gebruikt op lossy-formaten zoals JPEG. Hiermee kunt u elke afbeelding ongeveer zo veel als u wilt comprimeren, met dien verstande dat de kwaliteit slechter en slechter en slechter zal worden. Dingen zullen worden gepixeld en de definitie verliezen.
Lossless-compressie wordt gebruikt op indelingen zoals PNG en kan de bestandsgrootte enigszins verminderen. Het heeft echter zijn limieten. Er komt altijd een moment waarop het onmogelijk is om een afbeelding kleiner te maken zonder kwaliteit te verliezen.
Als je Photoshop of een vergelijkbaar geavanceerde beeldbewerker hebt, is het vaak het beste om die te gebruiken om je afbeeldingen te comprimeren, zodat je kunt zien hoe de uitvoer eruit zal zien als je klaar bent.
(Automatische tools, met name onlinetools, hebben naar mijn ervaring de neiging om dingen iets te ver te comprimeren, maar ik zal de beste compressietools vermelden die ik heb gevonden in het gedeelte links hieronder.)
Als u een CMS zoals WordPress gebruikt, wordt de grootte van afbeeldingen die te groot zijn automatisch verkleind. Het is ook eenvoudig om plug-ins te vinden die deze automatisch voor u comprimeren.
Let wel, ik raad alleen automatische compressie aan in gevallen waarin je weet dat je veel gaat uploaden, en veel afbeeldingen van vergelijkbare kwaliteit voor hetzelfde doel. Een fotoblog is een voorbeeld.
Als u een site gebruikt waarop gebruikers hun eigen afbeeldingen uploaden, is ... automatische aanpassing en compressie een absolute must, en daarom doet elk sociaal netwerk het.
Hier zijn een paar tips die niet in een van de bovenstaande drie categorieën pasten.
Het "verkleinen" van je code betekent alleen dat alle extra spaties en regeleinden worden verwijderd. Dit kan de bestandsgrootte behoorlijk aanzienlijk verminderen.
Het klinkt misschien als een hoop werk, maar er zijn tools beschikbaar om CSS en JS automatisch te verkleinen en de geminimaliseerde bestanden gescheiden te houden voor je bronbestanden, om vrij duidelijke redenen.
Zoals eerder vermeld, kunnen verschillende CSS-preprocessors al uw code in geminimaliseerde vorm uitvoeren.
Mits uw server correct is ingesteld, kan al uw code in gecomprimeerde vorm naar de browser worden verzonden. Tekstbestanden comprimeren erg goed, waardoor de grootte van de verzonden bestanden aanzienlijk wordt verkleind.
Nu moet uw server een paar ogenblikken duren om de bestanden die het verzendt te comprimeren en de browser van de gebruiker moet deze decomprimeren, maar meestal is dit de moeite waard om de bandbreedte te compenseren.
Zie voor een volledige uitleg over hoe dit werkt Hoe u uw site kunt optimaliseren met GZIP-compressie .
Browser-caching gebeurt automatisch tot op zekere hoogte dankzij moderne browsers. Een browser gaat naar een site en bewaart tijdelijk de afbeeldingen en andere informatie die hij daar aantreft.
Als dezelfde gebruiker binnen een bepaalde periode terugkeert, hoeft de browser niet opnieuw naar dezelfde afbeeldingen te vragen. Het laadt alleen degene die het al heeft en vraagt om nieuwe afbeeldingen die het misschien niet heeft.
Er is echter iets dat u kunt doen om browsers te vertellen wat ze moeten cachen en voor hoe lang, zoals te zien in deze gids .
En dan is er server caching. Server-caching neemt in feite gewoon uw site en plaatst een soort "kopie" ervan tussen uw gebruikers en uw werkelijke server. Waarom zou je de moeite nemen?
Nou, het is vooral handig voor mensen die op grote schaal content management systemen gebruiken. Als uw gebruikers toegang hebben tot een tijdelijke kopie van uw site in plaats van het daadwerkelijke, vermindert het aantal oproepen naar uw database. Informatie wordt sneller weergegeven en geladen omdat het niet elke keer opnieuw hoeft te worden verwerkt.
Afhankelijk van hoe het is ingesteld, kan servercaching ook de bandbreedtekosten in het algemeen verlagen. Kortom, hoe groter uw site is, des te meer reden dat u moet zoeken naar cachegeheugen.
En nu is de sectie waar u op hebt gewacht: de lijst met links! We hebben tutorials en gidsen, meestal, en een aantal hulpmiddelen voor beeldcompressie om aan te bevelen.
Yahoo! misschien niet zo groot als het ooit was, maar hun ontwikkelaarsnetwerk heeft veel goede dingen. Dit omvat hun Praktische tips voor het versnellen van uw website , dat enkele van de basisdingen behandelt die u kunt doen. Een deel ervan beslaat hetzelfde terrein als dit artikel, maar er is nog meer.
In de inleiding noemde ik waargenomen sitesnelheid, ook bekend als gepercipieerde prestaties. Lees hier meer over Een beginnershandleiding voor ervaren prestaties: 4 manieren om uw mobiele site als een inheemse app te laten voelen .
Effeckt.css is een set op CSS gebaseerde animaties die zijn ontworpen om snel te renderen, ongeacht het platform waarop de gebruiker zich bevindt.
Deze is een gids om ervoor te zorgen dat uw CSS zo snel mogelijk door de browser wordt gedownload en verwerkt.
Wanneer je net begint, leren correct te coderen kan een even grote snelheidsboost zijn als willekeurige willekeurige tips van trucs die u misschien leert. Slechte code kost meer in termen van verwerkingstijd, dus leer dingen op de juiste manier te doen.
Hier is een basisgids die zich meer specifiek richt op het schrijven van JavaScript dat snel werkt.
Net zoals de titel zegt, deze is alle advies specifiek gericht op JavaScript V8.
En soms gebruik je waarschijnlijk jQuery. Als je dat gaat doen, moet je tenminste weten hoe je jQuery-selectors moet schrijven die je niet vertragen. En hier is waar Sitepoint heeft je gedekt .
Lees dit voor meer informatie over afbeeldingsindelingen op internet. De informatie is een beetje oud, maar nog steeds geldig en goed om te weten.
Deze is een meer technische handleiding voor beeldoptimalisatie die wordt aangeboden door het Google Developer Network.
Compressor.io is een van de meer indrukwekkende tools die ik persoonlijk ben tegengekomen. Het is een online app, dus je moet alle bestanden uploaden die je wilt comprimeren, maar het kan wonderen doen voor JPG's. Het biedt zowel lossy als lossless compressie-opties, elk met behoorlijk verbluffende resultaten, en het kan ook batchverwerking uitvoeren.
Trimage is gespecialiseerd in compressie zonder verlies, maar kan op uw eigen computer, op Windows, Mac of Linux worden geïnstalleerd. Omdat het op uw computer wordt geïnstalleerd (en ja, wordt geleverd met verschillende opdrachtregelopties en een GUI), kan het eenvoudig automatisch worden uitgevoerd als onderdeel van een ontwikkelingsworkflow.
Zoals altijd is er nog veel meer te leren. Maar gewapend met de informatie die we hebben verstrekt en de bronnen waaraan we zijn gekoppeld, bent u op weg om sites en apps te bouwen die uw gebruikers niet irriteren.
En dat is de eerste stap om ze te imponeren.