Sedan etableringen av Internet har de genomsnittliga filstorlekarna stadigt ökat. Vad som började som kilobytes har utvecklats till megabyte (ja, flertalet), och våra filer växer bara fortfarande.
Även om detta fenomen inte är upprörande vid första anblicken, är konsekvensen av prestanda och underhållbarhet hemsk. Lägg till i åldrande enheter, bandbredd restriktioner eller långsamma hastigheter i allmänhet ... och vi har ett mycket större problem.
Tack och lov har vi kontroll över inte bara våra filstorlekar, utan också hur våra sidor görs i webbläsaren. Denna typ av kontroll ger webbutvecklare som oss en chans att hjälpa till att lindra detta problem, och optimera vår kod för bättre prestanda i processen.
Jag förstår fullständigt en brist på intresse när de flesta internetanslutningar i USA är ganska snabba idag. Jag menar, om allt fungerar bra, varför stör det?
Prestanda och optimering handlar om mer än hur snabbt vi kan hämta innehåll. Det finns också ganska många SEO- och UX-fördelar att få genom att ta sig tid att titta på vår kod. För att inte tala om, minskar filstorleken genom att optimera vår kod för bättre prestanda, har den extra bonusen att sänka våra bandbreddskostnader som värdar och minskar användningen av bandbredd (tänk ISP / celldata) på användarnivån.
Modulkod lägger vanligtvis uppblåst i form av fler alternativ. Här vill vi tänka modulära när det gäller att kombinera så många gemensamma delar av vår kod som möjligt. Om vi kan kombinera två CSS-klasser i en och använda mindre kod för att ge samma resultat, borde vi.
Modularitet är inte lika viktigt när det gäller grundläggande HTML och CSS, men när du kommer in i den mer komplexa världen av JavaScript kan det hända att du har för mycket uppblåsthet, särskilt på mobilen.
Beroende på förfrågningar är den överlägset största faktorn att sänka de flesta sidladdningshastigheter. Varje ytterligare förfrågan lägger till bloat och ett annat lager av komplexitet till analyserings- och nedladdningsprocessen. Det är ofta lätt att glömma att ringer bilder från ditt stilark också räknas också, så var noga med att begränsa dem och använd alternativa optimeringsmetoder som sprites eller SVG när det är möjligt.
Medan vi befinner oss på ämnet av externa beroenden, om din webbplats är tillräckligt stor för att kräva några dussinbegäran minst ... kan det vara dags att överväga att använda en CDN. Att använda en CDN för att distribuera ditt innehåll kommer inte att minska filstorlekar och / eller ladda gånger lika mycket som att ta bort extra HTTP-förfrågningar ihop, men det kan troligtvis ta bort långsamma servernsanslutningar ur ekvationen åtminstone.
Det borde finnas en väldigt stark skillnad när man jämför dina utvecklings- och produktionsnivåkodsbaser. Om du bara tar detta steg kan du ibland se den största minskningen av filstorlekar över hela linjen.
Det är typiskt idag att se utvecklare hänvisa till sin "produktion" eller "utveckling" miljö, särskilt på stora projekt. Men det är också användbart på den mindre änden av saker också. Den största skillnaden mellan de två miljöerna kan ses med bildkomprimering och kodning / komprimering av kod. I slutändan vill vi att vår produktionsmiljö ska vara så mager och snabb som möjligt medan vår utvecklingsmiljö ska vara densamma, bara minus optimering av bild / kodkomprimering.
Med hjälp av de inbyggda verktygen som Photoshops "Spara för webben" kan komprimering vara en bra utgångspunkt för bilder. Det finns en uppsjö av kunskap att vara utforskade någon annanstans samt med konversationer på bildformat, komprimeringsalgoritmer, kvalitetskontroll och bästa praxis.
För kod är den bästa användningen av komprimering vanligtvis beroende av vilket språk du arbetar med. Det är också mycket diskutabelt om komprimering av kod hjälper eller gör ont för andra som försöker förstå din kod, men det är en konversation för en annan gång. När det gäller vanlig HTML och CSS använder jag tjänster som Googles htmlcompressor och den YUI kompressor för CSS.
Ibland är själva koden vi skriver den långsammaste länken i kedjan. Ineffektivt CSS eller uppblåst JavaScript kan skada lastningstider mer än du kanske tror. Detta Mozilla posten går i stor detalj om vikten av att skriva mager CSS-selektörer och förklara hur webbläsare gör dem. Kort sagt, att skriva den exakta sökvägen längs en kedja av selektorer är mycket mindre effektiv än att bara använda den minsta unikt identifierbara väljaren istället. De båda leder stylingen till samma element, det senare gör jobbet gjort mycket, mycket snabbare.
JavaScript kan vara ännu värre än dåligt skrivet CSS, och i många fall är det enkelt förbisedt. Hur många gånger har du kopierat och klistrat ett externt JS-bibliotek i ditt projekt utan att verkligen titta på djupet vid källan själv? Typekit är ett underbart exempel på detta, som när deras servrar stallar det kan ta med en webbsida med sina teckensnitt på knä och orsaka ytterligare 30 sekunder eller till och med minuter med extra belastningstid.
Lyckligtvis händer sådana händelser sällan, men det är fortfarande bra att ringa JavaScript senast om möjligt, vilket är fallet med Google Analytics. Genom att göra så kan webbläsaren analysera huvudfilerna (CSS, HTTP-förfrågningar, etc.) och visa uppmärkningen innan JavaScript börjar sakta ner sakerna.
I överensstämmelse med vårt mål att skriva smidigare CSS-valörer och hålla uppblåst till ett minimum, bör det också vara prioriterat att skriva effektiv HTML.
CSS-återställningar riktar sig ofta mot alla vanliga element och verkställer "återställande" styling på dem. Så även om du inte riktar in sig på den extra diven, kommer det sannolikt fortfarande att sakta ner sakerna genom att behöva ha sin stoppning och marginalåterställning till ett minimum. Typiskt kommer en extra div eller två egentligen inte att skada något men. Bara när du börjar sluta med dussintals saker blir det galet. Med införandet av fler element i HTML5-specifikationen har vi också mycket mer flexibilitet inom detta område.
Google har prioriterat att piska Internet kollektivt i form. För att kunna uppta framträdande positioner inom sökresultaten måste sidorna nu kritiskt uppmärksamma många olika attribut om hur de görs. Ringa för många externa resurser, ha absurd stora bilder, eller till och med med dåligt skrivna JavaScript kan dra en plats ner i rangordningen.
Tack och lov är allt detta med god avsikt eftersom deras krav på en bra sökrankning bygger på goda utvecklingsmetoder. Google erbjuder också a mycket djupgående guide att optimera olika aspekter av din webbplats för bättre SEO - vilket också råkar gynna fantastiska utvecklingsmetoder samtidigt.
När vi optimerar vår kod måste vi inte bara tänka på filstorlekar utan också överväga hur den ska läsas. antingen av webbläsare eller till och med andra människor. Mobil användning bör också beaktas, med många tjänsteleverantörer som verkställer mycket begränsande datakapslar dessa dagar.
Så även om det kan ta extra tid att utföra all denna optimering, är det verkligen ett värdefullt försök, eftersom det inte bara ger bättre prestanda i webbläsaren och mobilen, men har också chansen att främja bättre utvecklingsmetoder och till och med få ditt innehåll en högre rang på sökmotorer som Google.
Nästa gång du förbereder dig för att starta, kasta dina bilder i en kompressionsmotor ... Du kan bli förvånad över hur många megabyte det kan raka av!