Innhold
- Prisen på å bremse ned
- Innholdsleveringsnettverk
- Ytterligere teknikker
- Henting og forhåndsvisning av hensyn
- Ajax innhold lastes
Denne artikkelen dukket først opp i nummer 231 av .net magazine - verdens mest solgte magasin for webdesignere og utviklere.
Hastighet bør være viktig for alle nettsteder. Det er et kjent faktum at Google bruker nettstedshastighet som rangeringsberegning for søkeresultatene. Dette forteller oss at besøkende foretrekker raske nettsteder - ingen overraskelse der!
Jakob Nielsen skrev i 1993 om svartidens tre grenser; selv om forskningen er gammel etter internettstandarder, har ikke psykologien vår endret seg mye i de mellomliggende 19 årene. Han uttaler at hvis et system reagerer på under 0,1 sekunder, vil det bli oppfattet som øyeblikkelig, mens svar raskere enn ett sekund gjør at brukerens tankestrøm forblir uavbrutt. Å ha en webside lastet inn på 0,1 sekunder er sannsynligvis umulig; rundt 0,34 sekunder representerer Googles beste lastetid, så dette fungerer som en mer realistisk (om enn ambisiøs) referanse. En sidelastning et sted i området 0,34 til 1 sekund er oppnåelig og viktig.
Prisen på å bremse ned
Denne typen mål har virkelige verdensimplikasjoner for nettstedet ditt og virksomheten. Googles Marissa Mayer snakket i 2006 om et eksperiment der antall resultater som ble returnert av søkemotoren ble økt til 30. Dette reduserte sidetiden med rundt 500 ms, med 20% trafikkfall som tilskrives dette. Imidlertid forsinket Amazon kunstig sideinnlastingen i trinn på 100 ms og fant at "selv veldig små forsinkelser ville resultere i betydelige og kostbare fall i inntektene".
Andre ugunstige tilknytninger knyttet til langsomme nettsteder inkluderer redusert troverdighet, lavere opplevd kvalitet og siden blir sett på som mindre interessant og attraktiv. Økt bruker frustrasjon og økt blodtrykk er to andre effekter vi sannsynligvis alle har opplevd på et tidspunkt! Men hvordan kan vi sørge for at nettstedene våre lastes raskt inn nok til å unngå disse problemene?
En av de første tingene å se på er størrelsen på HTML-koden. Dette er sannsynligvis et av de mest oversett områdene, kanskje fordi folk antar at det ikke lenger er så relevant med moderne bredbåndsforbindelser. Noen innholdshåndteringssystemer er ganske liberale med beløpet de slår ut - en grunn til at det kan være bedre å lage dine egne nettsteder.
Som en retningslinje bør du lett kunne passe de fleste sider i 50 KB med HTML-kode, og hvis du er under 20 KB, klarer du deg veldig bra. Det er åpenbart unntak, men dette er en ganske god tommelfingerregel.
Det er også viktig å huske på at folk surfer på fulle nettsteder oftere på mobile enheter nå. Hastighetsforskjeller mellom nettsteder sett fra en mobil er ofte mer merkbare på grunn av at de har lavere overføringshastigheter enn kablede forbindelser. To konkurrerende nettsteder med 100 KB størrelsesforskjell per side kan bety mer enn ett sekund tidsforskjell for belastning på noen langsomme mobilnett - godt inn i regionen 'avbrutt tankeflyt' spesifisert av Jakob Nielsen. Det raskere, raskere nettstedet kommer til å bli mye mindre frustrerende å bla gjennom, noe som gir et tydelig konkurransefortrinn over fetere nettsteder og går langt mot å oppmuntre til gjentatte besøk.
En viktig funksjon på de fleste webservere er muligheten til å servere HTML i komprimert format. Siden HTML av natur inneholder mye gjentatte data, gjør det det til en perfekt kandidat for komprimering. For eksempel er en hjemmesides 18,1 KB HTML redusert til 6,3 KB når den serveres i komprimert format. Det er en sparing på 65 prosent! Komprimeringsalgoritmer øker i effektivitet jo større teksttekst de må jobbe fra, slik at du vil se større besparelser med større HTML-sider. En 138,1 000-side på et populært forum reduseres til 25,7 000 når den serveres komprimert, en besparelse på over 80 prosent - noe som kan forbedre den totale overføringstiden for ressurser betydelig.
Det er praktisk talt ingen negativer ved å levere HTML i dette skjemaet; alle skal aktivere det for alt HTML-innholdet.Noen webservere har forskjellige innstillinger for komprimering av statisk og dynamisk generert innhold, så det er verdt å sikre at du leverer komprimert innhold for begge om mulig.
Innholdsleveringsnettverk
Innholdsleveringsnettverk (kjent som CDN) kan også forbedre lastetiden for nettstedet ditt betydelig. CDN-er er en samling servere distribuert over hele verden som alle har kopier av innholdet ditt. Når en bruker ber om et bilde fra nettstedet ditt som er vert på en CDN, vil serveren i CDN geografisk nærmest brukeren bli brukt til å betjene bildet.
Det er mange CDN-tjenester tilgjengelig. Noen av disse er veldig kostbare, men annonserer at de vil tilby bedre ytelse enn billigere CDN-er. Gratis CDN-tjenester har også begynt å dukke opp, og det kan være verdt å eksperimentere med for å se om de kan forbedre ytelsen på nettstedet ditt.
En viktig faktor når du bruker en CDN, er å sikre at du konfigurerer den riktig slik at du ikke mister noen SEO-verdi. Det kan hende du mottar mye trafikk fra bilder som er vert på domenet ditt, avhengig av nettstedet, og ved å flytte dem til et eksternt domene kan det påvirke trafikken din negativt. Amazon S3-tjenesten lar deg peke et underdomener til CDN-en, som er en svært foretrukket funksjon i et CDN.
Å vise innhold på et annet domene (for eksempel et CDN) eller et underdomener på ditt eget domenenavn som ikke angir informasjonskapsler, har en annen viktig fordel. Når en informasjonskapsel settes på et domene, sender nettleseren informasjonskapseldata med hver forespørsel til hver ressurs på det samme domenet. Oftere enn ikke er informasjonskapsler ikke påkrevd for statisk innhold som bilder, CSS eller JavaScript-filer. Nettbrukernes opplastningshastigheter er ofte mye langsommere enn tilgjengelige nedlastingsfrekvenser, noe som i noen tilfeller kan føre til betydelig nedgang i sidetiden. Ved å bruke et annet domenenavn for å betjene det statiske innholdet ditt, vil ikke nettlesere sende disse unødvendige informasjonskapslene, fordi de har strenge retningslinjer på tvers av domener. Dette kan øke forespørselstiden betydelig for hver ressurs.
Informasjonskapsler på nettsteder kan også ta opp det meste av en HTTP-forespørsel; 1500 byte er rundt den mest brukte grensen for enkeltpakker for store nettverk, så hvis du er i stand til å holde HTTP-forespørslene dine under denne grensen, skal hele HTTP-forespørselen sendes i en pakke. Dette kan gi forbedringer i sidetiden. Google anbefaler at informasjonskapslene dine skal være mindre enn 400 byte - dette strekker seg langt i retning av å holde nettsteder HTTP-forespørsler under grensen på én pakke / 1500 byte.
Ytterligere teknikker
Det finnes andre, enklere å implementere teknikker som kan gi store fordeler for nettstedets hastighet. Det ene er å plassere JavaScript-filene på slutten av HTML-dokumentet, rett før den avsluttende body-taggen, fordi nettlesere har begrensninger på hvor mange ressurser de kan laste ned parallelt fra samme vert.
Den opprinnelige HTTP 1.1-spesifikasjonen skrevet i 1999 anbefaler at nettlesere bare skal laste ned opptil to ressurser parallelt fra hvert vertsnavn. Men moderne nettlesere har som standard en grense på rundt seks. Hvis nettsiden din har mer enn seks eksterne ressurser (for eksempel bilder / JavaScript / CSS-filer), kan det gi deg bedre ytelse for å betjene dem fra flere domener (for eksempel et underdomenen på hoveddomenet eller et CDN) for å sikre nettleseren når ikke maksimumsgrensen for parallelle nedlastinger.
I stedet for å dele flere forespørsler på forskjellige domener, kan du vurdere å kombinere dem. Hver HTTP-forespørsel har en overhead tilknyttet. Dusinvis av bilder som ikoner på nettstedet ditt servert som separate ressurser vil skape mye sløsingskostnader og forårsake en avmatning på nettstedet ditt, ofte en betydelig. Ved å kombinere bildene dine til ett bilde, kjent som et 'sprite ark', kan du redusere antall forespørsler som kreves. For å vise bildet, definerer du det i CSS ved å stille inn elementets bredde og høyde til det bildet du vil vise, og deretter sette bakgrunnen til sprite-arket. Ved å bruke bakgrunn-posisjon eiendom kan vi flytte bakgrunnssprite-arket på plass slik at det vises på nettstedet ditt som det tiltenkte bildet.
Sprite-ark gir også andre fordeler. Hvis du bruker bilder med museoverføring, vil lagring av dem på det samme sprite-arket innebære at når museovergangen startes, er det ingen forsinkelse fordi museoverføringsbildet allerede er lastet inn i sprite-arket! Dette kan forbedre brukerens opplevde lastetid betydelig og skape et mye mer responsivt nettsted.
Spesifisere dimensjonene til andre bilder i img /> tagger er også en viktig faktor for å øke nettstedets opplevde lastetid. Det er vanlig at devs ikke eksplisitt angir bredde og høyde for bilder på sider. Dette kan føre til at sidens størrelse utvides i hopp når hvert bilde lastes inn (delvis), slik at ting føles svak. Hvis det er angitt eksplisitte dimensjoner, kan nettleseren reservere plass til bildet når det lastes inn, og hindre sidestørrelsen i å endre seg og noen ganger forbedre brukerens opplevde lastetid.
Så hva mer kan vi gjøre for å forbedre dette? Forhenting er en slik funksjon som er tilgjengelig i HTML5. Forhenting muliggjør lasting av sider og ressurser før brukeren faktisk har bedt om det. Støtten er for tiden begrenset til Firefox og Chrome (med en alternativ syntaks). Imidlertid er den enkle implementeringen og nytten for å forbedre den oppfattede lastetiden til websiden din så stor at det er noe å vurdere å implementere.
! —Firefox forhåndshenting -> link rel = "prefetch" href = "http://www.example.com/page2.html">! - Chrome Prerender -> link rel = "prerender" href = "http: / /www.example.com/page2.html">!— Begge i en linje -> link rel = "prefetch prerender" href = "http://www.example.com/page2.html">
Det er en atferdsforskjell mellom forhåndshenting og forhåndslevering. Mozilla’s forhåndshenting vil laste inn toppressursen for en gitt URL, vanligvis selve HTML-siden, og det er der innlastingen stopper. Google prerender laster også inn barnressurser, og i Googles ord "gjør alt arbeidet som er nødvendig for å vise siden til brukeren, uten å faktisk vise den før brukeren klikker".
Henting og forhåndsvisning av hensyn
Men å bruke denne funksjonen kommer også med viktige hensyn. Hvis du forhåndslegger / forhåndshenter for mange ressurser eller sider, kan det hende at brukerens hele nettleseropplevelse blir skadet. Hvis du har statistikk på serversiden, kan disse bli sterkt skjev. Hvis brukeren ikke klikker på den forhåndsinnlastede ressursen og går ut av nettstedet ditt, kan statistikksporeren din telle besøket som to sidevisninger, ikke som det faktiske. Dette kan være misvisende for viktige beregninger som avvisningsfrekvenser.
Chrome prerender har en annen advarsel utviklere må være klar over, ved at den forhåndsinnstilte siden vil utføre JavaScript. Forhåndslederen vil laste inn siden nesten nøyaktig på samme måte som om brukeren har klikket på lenken. Ingen spesielle HTTP-overskrifter sendes av Chrome med en forhåndsutbytte; Imidlertid lar Page Visibility API deg å skille om siden blir forhåndsutlevert. Dette er avgjørende viktig for tredjepartsskripter du bruker, for eksempel reklameskript og statistikksporere (Google Analytics bruker allerede API for Page-synlighet, slik at du ikke trenger å bekymre deg for det). Feil håndtering av disse eiendelene med Page Visibility API igjen gjør at du risikerer å vri viktige beregninger.
Ved hjelp av forhåndshenting og prerender på paginert innhold er sannsynligvis en trygg og nyttig implementering - for eksempel på en tutorials-webside som er delt inn i flere seksjoner. Spesielt på innhold som opplæringsprogrammer er det sannsynligvis viktig å holde seg innenfor Nielsens 'uavbrutt tankeflyt' -grenser.
Google Analytics kan også gi verdifulle ledetråder til hvilke sider du kanskje vil forhåndshente / forhåndshente. Ved hjelp av In-Page Analytics kan du bestemme hvilken lenke på hjemmesiden din mest sannsynlig blir klikket på. I noen tilfeller med høyt definerte oppfordringer til handling kan denne prosentandelen være ekstremt høy - noe som gjør den til en utmerket kandidat for forhåndslading.
Både forhåndshenting og forhåndslevering fungerer på tvers av domener - en uvanlig liberal holdning for nettlesere, som vanligvis er ekstremt strenge for tilgang på tvers av domener. Dette fungerer imidlertid sannsynligvis i Googles og Mozillas favør fordi de er i stand til å skape en raskere nettopplevelse for brukerne sine på flere måter, og tilbyr et betydelig konkurransefortrinn i forhold til andre nettlesere som ennå ikke støtter slike funksjoner.
Prehenting og spesielt forhåndsvisning er kraftige verktøy som kan ha betydelige forbedringer på de opplevde belastningstidene til nettsider. Men det er viktig å forstå hvordan de fungerer, slik at brukerens nettopplevelse ikke påvirkes direkte og negativt.
Ajax innhold lastes
En annen måte å forbedre lastetiden på er å bruke Ajax til å laste innhold i motsetning til å laste inn hele siden igjen - mer effektivt fordi det bare laster inn endringene, ikke kjeleplaten rundt innholdet hver gang.
Problemet med mye Ajax-lasting er at det kan føles som en unaturlig nettopplevelse. Hvis de ikke kjøres ordentlig, fungerer ikke bakover- og fremoverknappene slik brukeren forventer, og å utføre handlinger som å legge til bokmerker eller oppdatere siden, oppfører seg også på uventede måter. Når du utformer nettsteder, anbefales det å ikke forstyrre atferd som dette - det er veldig bekymringsfullt og uvennlig for brukerne. Et godt eksempel på dette vil være innsatsen noen nettsteder går til for å deaktivere høyreklikk på nettsidene deres som et nytteløst forsøk på å forhindre brudd på opphavsretten. Selv om implementering av Ajax ikke påvirker driften av nettleseren med den samme hensikten å deaktivere høyreklikking, er effektene like.
HTML5 går på en eller annen måte for å løse disse problemene med History API. Det støttes godt i nettlesere (bortsett fra Internet Explorer, selv om det er planlagt å støttes i IE10). Når vi arbeider med HTML5-historikk-API-et, kan vi laste innhold med Ajax, samtidig som vi simulerer en ‘normal’ nettleseropplevelse for brukerne. Når de brukes riktig fungerer knappene for rygg, fremover og oppdatering som forventet. Adresselinjens URL kan også oppdateres, noe som betyr at bokmerker nå fungerer som de skal igjen. Hvis du implementerer det riktig, kan du fjerne mye gjentatt innlasting av ressurser, samt å ha grasiøse tilbakeslag for nettlesere med JavaScript deaktivert.
Det er imidlertid en stor ulempe: avhengig av kompleksiteten og funksjonen til nettstedet du prøver å bygge, er det vanskelig å implementere Ajax-innholdsinnlasting med History API på en måte som er usynlig for brukeren. Hvis nettstedet også bruker skriptserver på serversiden, kan det også hende at du skriver ting to ganger: en gang i JavaScript og igjen på serveren - noe som kan føre til vedlikeholdsproblemer og inkonsekvenser. Det kan være vanskelig og tidkrevende å perfeksjonere, men hvis det fungerer etter hensikten, kan du redusere faktiske så vel som opplevde belastningstider for brukeren betydelig.
Når du prøver å forbedre hastigheten på nettstedet ditt, kan du støte på noen uløselige problemer. Som nevnt i begynnelsen av denne artikkelen er det ingen hemmelighet at Google bruker sidehastighet som rangering. Dette bør være en viktig motivasjon for å forbedre nettstedets hastighet. Du kan imidlertid merke at når du bruker ressurser som Googles nettredaktørverktøy, rapporterer de sidens hastighetsrapporter langsommere lastetider enn du forventer.
Årsaken kan være tredjepartsskript som Facebook Like-knapper eller Tweet-knapper. Disse kan ofte ha ventetider i hundrevis av millisekunder, noe som kan dra hele belastningstiden til nettstedet ditt betydelig. Men dette er ikke et argument for å fjerne disse skriptene - det er sannsynligvis viktigere å ha knappene på sosiale medier på nettstedet ditt. Disse knappene opptar vanligvis relativt små mellomrom på siden din, så det vil ikke påvirke den besøkendes opplevde lastetid vesentlig - det er det vi først og fremst burde ta vare på når vi foretar hastighetsoptimaliseringer.
Oppdag 101 CSS- og Javascript-opplæringsprogrammer på søstersiden vår, Creative Bloq.
