Sinds de oprichting van internet zijn de gemiddelde bestandsgroottes gestaag gegroeid. Wat begon als kilobytes is gevorderd tot megabytes (ja, meervoud) en onze bestanden groeien alleen maar.
Hoewel dit fenomeen op het eerste gezicht niet verontrustend is, is de impact ervan op de prestaties en onderhoudbaarheid vreselijk. Voeg ouder wordende apparaten, bandbreedtebeperkingen of lage snelheden toe in het algemeen ... en we hebben een veel groter probleem.
Gelukkig hebben we niet alleen controle over onze bestandsgroottes, maar ook over hoe onze pagina's in de browser worden weergegeven. Dit soort controle geeft webontwikkelaars zoals wijzelf een kans om dit probleem te verlichten en onze code te optimaliseren voor betere prestaties in het proces.
Ik begrijp een gebrek aan interesse volledig wanneer de meeste internetverbindingen in de VS tegenwoordig vrij snel zijn. Ik bedoel, als alles goed gaat, waarom zou je dan de moeite nemen?
Prestaties en optimalisatie gaan over meer dan hoe snel we inhoud kunnen downloaden. Er zijn ook behoorlijk wat SEO- en UX-voordelen te behalen door de tijd te nemen om naar onze code te kijken. Om nog maar te zwijgen, het verminderen van bestandsgroottes door het optimaliseren van onze code voor betere prestaties heeft de toegevoegde bonus van het verlagen van onze bandbreedtekosten als hosts, en vermindert het bandbreedtegebruik (denk ook aan ISP / cellulaire datacaps) op gebruikersniveau.
Modulaire code voegt typisch bloat toe in de vorm van meer opties. Hier willen we modulair denken in termen van het combineren van zoveel mogelijk gemeenschappelijke delen van onze code. Als we twee CSS-klassen in één kunnen combineren en minder code gebruiken om hetzelfde resultaat te bieden, zouden we dat moeten doen.
Modulariteit is niet zo belangrijk als het gaat om eenvoudige HTML en CSS, maar als je in de meer complexe wereld van JavaScript komt, kan het hebben van te veel problemen je pijn doen - vooral op mobiel.
Afhankelijkheidsverzoeken zijn verreweg de grootste factor in het vertragen van de meeste laadsnelheden van pagina's. Elk extra verzoek voegt een zwelling en een andere laag van complexiteit toe aan het parseer- en downloadproces. Het is vaak gemakkelijk om te vergeten dat het oproepen van afbeeldingen uit uw stylesheet ook meetelt, dus zorg ervoor dat u deze beperkt en gebruik indien mogelijk alternatieve optimalisatiemethoden zoals sprites of SVG.
Hoewel we het over externe afhankelijkheden hebben, als uw website groot genoeg is om een paar tientallen verzoeken op minimaal te vereisen ... Het is misschien tijd om een CDN te overwegen. Als u een CDN gebruikt om uw inhoud te distribueren, neemt de bestandsgrootte en / of laadtijd niet zo veel af als wanneer u extra HTTP-aanvragen tegelijk verwijdert, maar het kan waarschijnlijk alle langzame serververbindingen op zijn minst uit de vergelijking verwijderen.
Er zou een heel sterk verschil moeten zijn bij het vergelijken van uw ontwikkel- en productieniveaucodebasissen. Alleen al het nemen van deze stap kan soms de grootste afname in bestandsgroottes over het hele bord zien.
Het is tegenwoordig typisch om te zien dat ontwikkelaars verwijzen naar hun "productie" - of "ontwikkelings" -omgeving, vooral bij grootschalige projecten. Maar het is ook nuttig aan de kleinere kant van de dingen. Het grootste verschil tussen de twee omgevingen is te zien met beeldcompressie en het verkleinen / comprimeren van code. Uiteindelijk willen we dat onze productieomgeving zo soepel en snel mogelijk is, terwijl onze ontwikkelomgeving hetzelfde moet zijn, maar dan minus de optimalisatie van de image / code-compressie.
Het gebruik van de ingebouwde hulpmiddelen zoals de "Opslaan voor web" -compressie van Photoshop kan een goed beginpunt zijn voor afbeeldingen. Er is een overvloed aan kennis om te zijn elders onderzocht ook met gesprekken over beeldformaten, compressiealgoritmen, kwaliteitscontrole en best practices.
Voor code is het beste gebruik van compressie meestal afhankelijk van de taal waarmee u werkt. Het is ook zeer discutabel of compressie van code anderen helpt of probeert te schaden die proberen je code te begrijpen, maar dat is een gesprek voor een andere keer. Als het gaat om gewone HTML en CSS, gebruik ik diensten zoals Google's htmlcompressor en de YUI-compressor voor CSS.
Soms is de code die we schrijven de langzaamste schakel in de keten. Inefficiënte CSS of opgeblazen JavaScript kunnen de laadtijden meer schaden dan je denkt. Deze Mozilla post gaat in grote details over het belang van het schrijven van lean CSS selectors en uitleg over hoe browsers ze renderen. Kortom, het schrijven van het exacte pad in een keten van selectors is veel minder efficiënt dan simpelweg het gebruik van de kleinste, uniek identificeerbare selector. Ze richten allebei de styling op hetzelfde element, de laatste doet de klus gewoon veel, veel sneller.
JavaScript kan zelfs erger zijn dan slecht geschreven CSS, en in veel gevallen wordt het gemakkelijk over het hoofd gezien. Hoe vaak heb je een externe JS-bibliotheek in je project gekopieerd en geplakt zonder echt diepgaand naar de bron zelf te kijken? Typekit is hiervan een prachtig voorbeeld, want wanneer hun servers blokkeren, kan een webpagina met behulp van hun lettertypen op de knieën komen en een extra 30 seconden of zelfs minuten extra laadtijd veroorzaken.
Gelukkig gebeuren dergelijke gebeurtenissen zelden, maar het is nog steeds een goede gewoonte om JavaScript zo lang mogelijk te gebruiken, zoals het geval is met Google Analytics. Hierdoor kan de browser de headbestanden (CSS, HTTP-aanvragen, enz.) Analyseren en de markup weergeven, voordat JavaScript begint te vertragen.
In overeenstemming met ons doel om slankere CSS-kiezers te schrijven en de bloat tot een minimum te beperken, zou het schrijven van efficiënte HTML ook een prioriteit moeten zijn.
CSS-resets targeten vaak alle gangbare elementen en zorgen ervoor dat ze worden 'gereset'. Dus zelfs als u niet die extra div target, zal het waarschijnlijk nog steeds vertragen door de vulling en marge-reset minimaal te moeten hebben. Normaal gesproken zal een extra div of twee niet echt pijn doen. Pas als je met tientallen van hen eindigt, worden dingen gek. Met de introductie van meer elementen in de HTML5-specificatie, hebben we ook veel meer flexibiliteit op dit gebied.
Google heeft er een prioriteit van gemaakt om het internet collectief in vorm te krijgen. Om prominente posities in hun zoekresultaten in te nemen, moeten pagina's nu kritisch aandacht besteden aan veel verschillende kenmerken over hoe ze worden weergegeven. Het bellen van te veel externe bronnen, met absurd grote afbeeldingen of zelfs slecht geschreven JavaScript kan een site naar beneden halen in de rangorde.
Gelukkig is dit alles met een goede intentie, omdat hun vereisten voor een goede ranking in de zoekresultaten gebaseerd zijn op goede ontwikkelingspraktijken. Google biedt ook een zeer diepgaande gids om verschillende aspecten van uw site te optimaliseren voor betere SEO - wat ook gebeurt om tegelijkertijd fantastische ontwikkelingspraktijken te promoten.
Bij het optimaliseren van onze code moeten we niet alleen nadenken over bestandsgroottes, maar ook nadenken over hoe deze wordt gelezen; door browsers of zelfs door andere mensen. Er moet ook rekening worden gehouden met mobiel gebruik, waarbij veel serviceproviders tegenwoordig zeer beperkende datamaps afdwingen.
Dus hoewel het wellicht extra tijd kost om al deze optimalisaties uit te voeren, is het zeker de moeite waard, omdat het niet alleen betere prestaties biedt in de browser en op mobiele apparaten, maar ook de kans biedt om betere ontwikkelmethoden te promoten en zelfs uw inhoud een hogere rang te krijgen. op zoekmachines zoals Google.
De volgende keer dat u zich voorbereidt om te starten, gooit u uw afbeeldingen in een compressie-engine ... U zult er versteld van staan hoeveel megabytes het kan afscheren!
Uitgelichte afbeelding, modulaire snelheid afbeelding via Shutterstock.