Siden etableringen av Internett har gjennomsnittlige filstørrelser vokst jevnt. Det som startet som kilobytes har utviklet seg til megabyte (ja, flertall), og våre filer vokser bare fremdeles.
Selv om dette fenomenet ikke er foruroligende ved første øyekast, er virkningen det har på ytelse og vedlikehold, forferdelig. Legg til i aldringsenheter, begrensninger for båndbredde eller lave hastigheter generelt ... og vi har et mye større problem.
Heldigvis har vi kontroll over ikke bare våre filstørrelser, men også hvordan våre sider gjengis i nettleseren. Denne typen kontroll gir webutviklere som oss selv en sjanse til å lette dette problemet, og optimalisere koden vår for bedre ytelse i prosessen.
Jeg forstår fullt ut en mangel på interesse når de fleste internettforbindelser i USA er ganske raske i disse dager. Jeg mener, hvis alt fungerer bra allerede hvorfor bry?
Ytelse og optimalisering handler om mer enn hvor raskt vi kan laste ned innhold. Det er også ganske mange SEO- og UX-fordeler å få ved å ta deg tid til å se på koden vår. For ikke å nevne, redusere filstørrelser ved å optimalisere koden vår for bedre ytelse, har den ekstra bonusen å redusere vår båndbredde kostnader som verter, og reduserer bruken av båndbredde (tenk ISP / celledatabord) på brukernivå også.
Modulær kode legger vanligvis opp i form av flere alternativer. Her ønsker vi å tenke modulær når det gjelder å kombinere så mange vanlige deler av koden som mulig. Hvis vi kan kombinere to CSS-klasser i en og bruke mindre kode for å gi det samme resultatet, bør vi.
Modularitet er ikke så viktig når det kommer til grunnleggende HTML og CSS, men når du kommer inn i den mer komplekse verden av JavaScript, kan det hende at du har for mye oppblåsthet - spesielt på mobilen.
Avhengighetsforespørsler er langt den største faktoren ved å bremse ned de fleste sidelastningshastigheter. Hver tilleggsforespørsel legger til oppblåsthet og et annet lag av kompleksitet til parsing og nedlastingsprosessen. Det er ofte enkelt å glemme at ringesignaler fra stilarket også teller også, så vær sikker på å begrense dem og bruk alternative optimaliseringsmetoder som sprites eller SVG når det er mulig.
Mens vi er på emnet av eksterne avhengigheter, hvis nettstedet ditt er stort nok til å kreve noen få dusin forespørsler på minimum ... Det kan være på tide å vurdere å bruke en CDN. Ved å bruke en CDN til å distribuere innholdet ditt, reduseres ikke filstørrelser og / eller lastetider så mye som å fjerne flere HTTP-forespørsler alt sammen, men det kan sannsynligvis fjerne eventuelle sakte serverforbindelser utelukkende fra ligningen.
Det bør være en veldig sterk forskjell når du sammenligner utviklings- og produksjonsnivåkoden. Å ta dette skritt alene kan noen ganger se den største nedgangen i filstørrelser over hele linjen.
Det er typisk i dag å se utviklere referere til deres "produksjon" eller "utvikling" miljø, spesielt på store prosjekter. Men det er også nyttig på den mindre enden av tingene også. Den største forskjellen mellom de to miljøene kan sees med bildekomprimering og minifisering / komprimering av kode. Til slutt vil vi at vårt produksjonsmiljø skal være så mager og rask som mulig, mens utviklingsmiljøet vårt bør være det samme, bare minus bildet / kodekompresjonsoptimaliseringen.
Ved hjelp av de innebygde verktøyene som Photoshops "Save for web" -komprimering kan være et godt utgangspunkt for bilder. Det er en mengde kunnskap å være utforsket andre steder samt med samtaler på bildeformater, komprimeringsalgoritmer, kvalitetskontroll og beste praksis.
For kode, er den beste bruken av komprimering vanligvis avhengig av språket du jobber med. Det er også svært diskutabelt om komprimering av kode hjelper eller gjør vondt til andre som prøver å forstå koden din, men det er en samtale for en annen gang. Når det gjelder ren HTML og CSS, bruker jeg tjenester som Googles htmlcompressor og YUI kompressor for CSS.
Noen ganger er selve koden vi skriver, den tregeste lenken i kjeden. Ineffektiv CSS eller oppblåst JavaScript kan skade lastetider mer enn du kanskje tror. Dette Mozilla innlegget går i stor detalj om viktigheten av å skrive magert CSS-selektorer og forklare hvordan nettlesere gjengir dem. Kort sagt, å skrive den nøyaktige banen nedover en kjede av selektorer er mye mindre effektiv enn å bare bruke den minste unikt identifiserbare selgeren i stedet. De begge leder stylingen til det samme elementet, sistnevnte gjør jobben gjort mye, mye raskere.
JavaScript kan være enda verre enn dårlig skrevet CSS, og i mange tilfeller er det lett oversett. Hvor mange ganger har du kopiert og limt et eksternt JS-bibliotek inn i prosjektet ditt uten å se nærmere på selve kilden? Typekit er et flott eksempel på dette, som når serverne staller det kan bringe en nettside ved hjelp av skrifttyper på knærne og forårsake ytterligere 30 sekunder eller til og med minutter med ekstra belastningstid.
Heldigvis skjer slike hendelser sjelden, men det er fortsatt god praksis å ringe JavaScript sist hvis det er mulig, slik det er tilfelle med Google Analytics. Dette gjør at nettleseren kan analysere hovedfilene (CSS, HTTP-forespørsler, osv.) Og vise oppmerkningen, før JavaScript begynner å senke sakene.
I tråd med vårt mål om å skrive slankere CSS-selektorer og holde oppblåst til et minimum, bør det også være en prioritet å skrive effektiv HTML.
CSS tilbakestiller ofte målrette mot alle vanlige elementer og håndheve "tilbakestilling" styling på dem. Så selv om du ikke målretter mot den ekstra div, vil det sannsynligvis fortsatt bremse tingene ned ved å ha sin polstring og marginal tilbakestilling på et minimum. Vanligvis vil en ekstra div eller to egentlig ikke skade noe selv. Bare når du begynner å ende opp med dusinvis av dem, blir ting galne. Med introduksjonen av flere elementer i HTML5-spesifikasjonen, har vi også mye mer fleksibilitet på dette området også.
Google har gjort det til en prioritet å peke på Internett kollektivt i form. For å kunne okkupere fremtredende stillinger i søkeresultatene må sidene nå gi kritisk oppmerksomhet til mange forskjellige attributter om hvordan de blir gjort. Kaller for mange eksterne ressurser, har absurde store bilder, eller til og med å ha dårlig skrevet JavaScript, kan trekke et nettsted ned i rangering.
Heldigvis skjønt, dette er alt med god intensjon, da deres krav til en god søkrangeringen er bygget rundt gode utviklingspraksis. Google tilbyr også en veldig dybtgående guide å optimalisere ulike aspekter av nettstedet ditt for bedre SEO - som også skjer for å fremme fantastiske utviklingspraksis på samme tid.
Når vi optimaliserer koden, må vi ikke bare tenke på filstørrelser, men også vurdere hvordan det blir lest. enten av nettlesere eller til og med andre mennesker. Mobilbruk bør også tas i betraktning, med mange tjenesteleverandører som håndhever svært begrensede datakort i disse dager.
Så selv om det kan ta ekstra tid å utføre all denne optimaliseringen, er det absolutt et verdifullt forsøk, siden det ikke bare gir bedre ytelse i nettleseren og mobilen, men har også muligheten til å fremme bedre utviklingspraksis og til og med få innholdet ditt høyere rangere på søkemotorer som Google.
Neste gang du forbereder deg til å starte, kaster du bildene til en komprimeringsmotor ... Du kan bli overrasket over hvor mange megabyte det kan barbere seg av!