Tid til første byte (TTFB)

Tid til første byte måler intervallet mellom en nettleser ber om en ressurs og mottar den første byten av svaret. Den aggregerer flere forskjellige faser: omdirigeringer, DNS-løsning, etablering av tilkobling, TLS-forhandling, selve forespørselen og serverens behandlingstid før den begynner å svare. Fordi alt annet i sideinnlasting avhenger av at dette svaret ankommer, fungerer den som et gulv under alle nedstrøms innlastingsmålinger.

Den diagnostiske verdien kommer fra den posisjonen i sekvensen. En side med en treg, største innholdsbaserte maling og en rask første byte har et frontend-problem, i levering av ressurser, gjengivelse eller blokkering av ressurser. Den samme siden med en treg første byte har et backend- eller nettverksproblem, og ingen mengde bildeoptimalisering eller skriptutsettelse vil fikse det, fordi nettleseren ennå ikke har mottatt noe å jobbe med. Å fastslå hvilken av disse som gjelder er det første trinnet i enhver seriøs ytelsesundersøkelse.

De medvirkende årsakene deles inn i nettverks- og serverkategorier. På nettverkssiden legger geografisk avstand mellom den besøkende og den opprinnelige serveren til uunngåelig latens, omdirigeringskjeder legger til en full rundtur hver, og tilkobling og TLS-forhandling legger til ytterligere rundturer for nye tilkoblinger. På serversiden er treg applikasjonskode, uindekserte eller ineffektive databasespørringer, kall til eksterne tjenester gjort synkront under forespørselen, manglende eller ineffektiv mellomlagring og ressurskonflikt på delt hosting de vanlige årsakene.

Løsningene varierer deretter. Innholdsleveringsnettverk håndterer avstand ved å betjene fra steder i nærheten av den besøkende, og kan betjene mellomlagrede svar helt fra kanten uten å kontakte opprinnelsen. Mellomlagring på flere lag, inkludert mellomlagring av helsides-, fragment-, objekt- og databasespørringer, fjerner gjentatt arbeid. Eliminering av omdirigeringskjeder fjerner hele rundturer, som ofte er den største tilgjengelige forbedringen på nettsteder med eldre URL-strukturer. Moderne protokoller og gjenbruk av tilkoblinger reduserer forhandlingsoverhead. På applikasjonssiden adresserer spørringsoptimalisering og flytting av ikke-essensielt arbeid ut av forespørselsbanen serverkomponenten.

Målinger bør skille mellom hurtigbufrede og ikke-hurtige svar, og mellom første- og gjentatte besøk, siden disse kan variere med en størrelsesorden, og et gjennomsnitt skjuler begge deler. Feltdata segmentert etter geografi og tilkoblingstype er mer informative enn et enkelt tall, fordi et nettsted med akseptable totaltall kan betjene ett marked svært dårlig. Testing fra stedet der nettstedet er vert, som er den vanlige standarden, undervurderer systematisk hva fjerne besøkende opplever.

Trefffrekvens for hurtigbuffer er den mest nyttige diagnostikken når man undersøker denne målingen på et nettsted bak et innholdsleveringsnettverk, og den er ofte dårlig av årsaker som er enkle å korrigere. Svar som er merket som ikke-cacherbare som standard, hurtigbuffernøkler fragmentert av sporingsparametere eller unødvendige overskrifter, og korte utløpstider fører alle til at forespørsler når opprinnelsen som ikke trenger å gjøre det. Å måle andelen forespørsler som betjenes fra kanten, og undersøke hva som skiller feilene, identifiserer vanligvis et lite antall konfigurasjonsbeslutninger som er ansvarlige for de fleste av dem. Å forbedre denne andelen reduserer både ventetid for besøkende og belastningen på opprinnelsen, noe som forbedrer svarene som virkelig må genereres.

Fordi forbedring vanligvis krever endringer i infrastruktur, mellomlagringsstrategi eller applikasjonskode snarere enn i frontend-ressurser, er dette tiltaket der ytelsesarbeid oftest går fra presentasjonslaget til prosjekteringslaget. I praksis håndteres det i fellesskap av nettytelse og produktutvikling, og det er ofte denne begrensningen som må løses først, siden frontend-optimalisering brukt oppå en treg opprinnelse gir skuffende resultater som deretter feilaktig tilskrives optimaliseringsarbeidet.