Siden oprettelsen af internettet har de gennemsnitlige filstørrelser været stadigt stigende. Hvad der startede som kilobytes har udviklet sig til megabyte (ja, flertallet), og vores filer vokser kun stadig.
Selv om dette fænomen ikke er foruroligende ved første øjekast, er det forfærdeligt, at det har en indvirkning på ydeevne og vedligeholdelse. Tilføj i aldringsenheder, båndbreddebegrænsninger eller lave hastigheder generelt ... og vi har et meget større problem.
Heldigvis har vi kontrol over ikke kun vores filstørrelser, men også hvordan vores sider gengives i browseren. Denne form for kontrol giver webudviklere som os selv en chance for at lette dette problem og optimere vores kode for bedre ydeevne i processen.
Jeg forstår fuldstændig manglende interesse, når de fleste internetforbindelser i USA er ret hurtige i disse dage. Jeg mener, hvis alting virker fint, hvorfor hvorfor genere det?
Ydeevne og optimering handler om mere end, hvor hurtigt vi kan downloade indhold. Der er også ganske få SEO- og UX-fordele, der skal være ved at tage sig tid til at se på vores kode. For ikke at nævne, faldende filstørrelser ved at optimere vores kode for bedre ydeevne er den ekstra bonus at reducere vores båndbreddeomkostninger som værter, og nedsætter båndbreddeanvendelsen (tænk ISP / celledatabase) på brugerniveau også.
Modulær kode tilføjer typisk opblussen i form af flere muligheder. Her ønsker vi at tænke modulære med hensyn til at kombinere så mange fælles stykker af vores kode som muligt. Hvis vi kan kombinere to CSS klasser i en og bruge mindre kode for at give det samme resultat, skal vi.
Modularitet er ikke så vigtigt, når det kommer til grundlæggende HTML og CSS, men når du kommer ind i den mere komplekse verden af JavaScript, kan det være for ondt at have for meget - især på mobilen.
Afhængighedsanmodninger er langt den største faktor ved at bremse de fleste sidelasthastigheder. Hver yderligere anmodning tilføjer bloat og et andet lag af kompleksitet til parsing og download processen. Det er ofte nemt at glemme, at kaldende billeder fra dit stylesheet også tæller også, så sørg for at begrænse dem og brug alternative optimeringsmetoder som sprites eller SVG når det er muligt.
Mens vi er på emnet eksterne afhængigheder, hvis din hjemmeside er stor nok til at kræve et par dusin anmodninger på minimum ... Det kan være på tide at overveje at bruge en CDN. Brug af en CDN til at distribuere dit indhold reducerer ikke filstørrelser og / eller indlæsningstider så meget som at fjerne flere HTTP-anmodninger alt sammen, men det kan sandsynligvis fjerne eventuelle langsomme serverforbindelser ud af ligningen.
Der bør være en meget skarp forskel, når du sammenligner dine udviklings- og produktionsniveaukodebaser. Hvis du kun tager dette trin, kan du undertiden se det største fald i filstørrelser på tværs af bordet.
Det er typisk i dag at se udviklere henvise til deres "produktion" eller "udvikling" miljø, især på store projekter. Men det er også nyttigt på den mindre ende af tingene også. Den største forskel mellem de to miljøer kan ses med billedkomprimering og kodningens komprimering / komprimering. Til sidst ønsker vi, at vores produktionsmiljø skal være så magert og hurtigt som muligt, mens vores udviklingsmiljø skal være det samme, kun minus optimering af billed- / kodekomprimering.
Ved hjælp af de indbyggede værktøjer som Photoshops "Save for web" komprimering kan være et godt udgangspunkt for billeder. Der er en overflod af viden at være udforsket andetsteds samt med samtaler på billedformater, komprimeringsalgoritmer, kvalitetskontrol og bedste praksis.
For kode er den bedste brug af komprimering normalt afhængig af det sprog, du arbejder med. Det er også meget diskutabelt, om komprimering af kode hjælper eller gør ondt til andre, der forsøger at forstå din kode, men det er en samtale til en anden gang. Når det kommer til almindelig HTML og CSS, bruger jeg tjenester som Googles htmlcompressor og YUI Kompressor for CSS.
Nogle gange er den meget kode, vi skriver, den langsomste link i kæden. Ineffektiv CSS eller oppustet JavaScript kan skade belastningstider mere, end du måske tror. Det her Mozilla posten går i stor detaljer om vigtigheden af at skrive lean CSS selectors og forklare, hvordan browsere gør dem. Kort sagt, at skrive den nøjagtige vej ned ad en selektor er meget mindre effektiv end at bruge den mindste unikke identificerbare vælger i stedet. De begge leder stylingen til det samme element, sidstnævnte får simpelthen jobbet meget, meget hurtigere.
JavaScript kan være endnu værre end dårlig skrevet CSS, og i mange tilfælde er det let overset. Hvor mange gange har du kopieret og indsat et eksternt JS-bibliotek i dit projekt uden at kigge dybt i selve kilden? Typekit er et vidunderligt eksempel på dette, som når deres servere stal det kan bringe en webside ved hjælp af deres skrifttyper på knæ og forårsage yderligere 30 sekunder eller endda minutter ekstra belastningstid.
Heldigvis sker sådanne begivenheder sjældent, men det er stadig god praksis at kalde JavaScript sidst, hvis det er muligt, som det er tilfældet med Google Analytics. Dette gør det muligt for browseren at analysere hovedfilerne (CSS, HTTP-anmodninger osv.) Og vise markeringen, før JavaScript begynder at bremse tingene ned.
I overensstemmelse med vores mål om at skrive slankere CSS-selektorer og holde opblussen til et minimum, bør det også være en prioritet at skrive effektiv HTML.
CSS nulstiller ofte målrettet mod alle fælles elementer og håndhæver "nulstiller" styling på dem. Så selvom du ikke målretter mod den ekstra div, er det sandsynligvis stadig ved at bremse tingene ned ved at have sin polstring og margen nulstillelse til et minimum. Typisk vil en ekstra div eller to ikke virkelig skade noget selvom. Først når du begynder at ende med snesevis af dem, bliver tingene gale. Med introduktionen af flere elementer i HTML5-spec har vi også meget mere fleksibilitet på dette område.
Google har gjort det til en prioritet at piske internettet kollektivt i form. For at besidde fremtrædende positioner inden for deres søgeresultater skal siderne nu give kritisk opmærksomhed til mange forskellige egenskaber om, hvordan de bliver gjort. At ringe for mange eksterne ressourcer, have absurde store billeder eller endda have dårligt skrevet JavaScript kan trække et websted ned i rangordningen.
Heldigvis er alt dette med god hensigt, da deres krav til en god søgerrangering er bygget op omkring god udviklingspraksis. Google tilbyder også a meget dybtgående vejledning at optimere forskellige aspekter af dit websted for bedre SEO - hvilket også sker for at fremme fantastiske udviklingspraksis på samme tid.
Når vi optimerer vores kode, skal vi ikke blot tænke på filstørrelser, men også overveje, hvordan den bliver læst; enten af browsere eller endda andre mennesker. Mobil brug bør også tages i betragtning, med mange tjenesteudbydere håndhæve meget begrænsede datakapsler i disse dage.
Så selvom det kan tage ekstra tid at udføre al denne optimering, er det bestemt et værdifuldt forsøg, da det ikke kun giver bedre ydeevne i browseren og mobilen, men har også mulighed for at fremme bedre udviklingspraksis og endda få dit indhold højere på søgemaskiner som google
Næste gang du forbereder dig til at lancere, smider dine billeder i en kompressionsmotor ... Du kan blive overrasket over, hvor mange megabyte det kan barbere sig af!
Udvalgte billede, modulopbygget hastighedsbillede via Shutterstock.