We hebben Microsoft Clarity benadrukt als een product dat is ontwikkeld met praktische, realistische gebruiksscenario's in gedachten door echte productontwikkelaars die de uitdagingen begrijpen waar bedrijven zoals Switas mee te maken hebben. Functies zoals 'rage clicks' en JavaScript-foutopsporing bleken van onschatbare waarde bij het identificeren van frustraties van gebruikers en technische problemen, waardoor gerichte verbeteringen mogelijk werden die een directe impact hadden op de gebruikerservaring en conversieratio's.
Tijd tot eerste byte (TTFB)
De Time to First Byte (TTF) meet het tijdsinterval tussen het moment dat een browser een bron opvraagt en het moment dat de eerste byte van het antwoord wordt ontvangen. Het omvat verschillende afzonderlijke fasen: omleidingen, DNS-resolutie, het tot stand brengen van de verbinding, TLS-onderhandeling, het verzoek zelf en de verwerkingstijd van de server voordat deze begint met reageren. Omdat alles in het laadproces van een pagina afhankelijk is van de aankomst van dit antwoord, fungeert TFT als een ondergrens voor alle daaropvolgende laadmetingen.
De diagnostische waarde ervan komt voort uit de positie in de sequentie. Een pagina met een trage 'largest contentful paint' en een snelle 'first byte' heeft een front-endprobleem, bijvoorbeeld met de levering van assets, de rendering of het blokkeren van resources. Dezelfde pagina met een trage 'first byte' heeft een back-end- of netwerkprobleem, en geen enkele vorm van beeldoptimalisatie of scriptuitstel zal dit oplossen, omdat de browser nog niets heeft ontvangen om mee te werken. Vaststellen welke van deze problemen van toepassing is, is de eerste stap in elk serieus prestatieonderzoek.
De oorzaken vallen uiteen in netwerk- en servercategorieën. Aan de netwerkzijde zorgt de geografische afstand tussen de bezoeker en de server voor onvermijdelijke vertraging, redirect-ketens voegen elk een volledige retourvlucht toe en verbindings- en TLS-onderhandelingen zorgen voor nog meer retourvluchten bij nieuwe verbindingen. Aan de serverzijde zijn trage applicatiecode, niet-geïndexeerde of inefficiënte databasequery's, gelijktijdige aanroepen van externe services tijdens het verzoek, ontbrekende of ineffectieve caching en resourceconflicten op shared hosting de gebruikelijke oorzaken.
De oplossingen verschillen dienovereenkomstig. Content Delivery Networks (CDN's) pakken de afstand aan door te serveren vanaf locaties dicht bij de bezoeker en kunnen cachebare antwoorden volledig vanaf de rand van het netwerk leveren zonder contact op te nemen met de bron. Caching op meerdere niveaus, waaronder caching van volledige pagina's, fragmenten, objecten en databasequery's, elimineert herhaald werk. Het elimineren van redirect-ketens elimineert volledige roundtrips, wat vaak de grootste verbetering is die beschikbaar is voor sites met verouderde URL-structuren. Moderne protocollen en hergebruik van verbindingen verminderen de overhead van de onderhandeling. Aan de applicatiezijde pakken query-optimalisatie en het verplaatsen van niet-essentiële taken uit het aanvraagpad de servercomponent aan.
Bij metingen moet onderscheid worden gemaakt tussen in de cache opgeslagen en niet-gecacheerde reacties, en tussen eerste en herhaalde bezoeken, aangezien deze aanzienlijk van elkaar kunnen verschillen en een gemiddelde beide verhult. Veldgegevens, gesegmenteerd naar geografische locatie en verbindingstype, zijn informatiever dan een enkel cijfer, omdat een website met acceptabele algemene cijfers een bepaalde markt mogelijk zeer slecht bedient. Testen vanaf de locatie waar de website wordt gehost, wat vaak de standaard is, onderschat systematisch wat bezoekers van buitenaf ervaren.
De cache-hitrate is de meest nuttige diagnostische indicator bij het onderzoeken van deze statistiek op een website achter een content delivery network (CDN), en deze is vaak laag om redenen die gemakkelijk te verhelpen zijn. Reacties die standaard als niet-cachebaar zijn gemarkeerd, cache-sleutels die gefragmenteerd zijn door trackingparameters of onnodige headers, en korte vervaltijden zorgen er allemaal voor dat verzoeken de server bereiken die daar niet hoeven te zijn. Door het percentage verzoeken te meten dat vanaf de edge wordt afgehandeld en te onderzoeken wat de missers onderscheidt, wordt meestal een klein aantal configuratiebeslissingen geïdentificeerd die verantwoordelijk zijn voor de meeste missers. Het verbeteren van dat percentage vermindert zowel de latentie voor bezoekers als de belasting van de server, wat de reacties die daadwerkelijk gegenereerd moeten worden verbetert.
Omdat verbeteringen meestal aanpassingen vereisen aan de infrastructuur, de cachingstrategie of de applicatiecode in plaats van aan de front-end, is dit de plek waar prestatieverbeteringen het vaakst van de presentatielaag naar de engineering overgaan. In de praktijk wordt dit gezamenlijk aangepakt door... webprestaties en productontwikkelingEn vaak is het juist die beperking die als eerste moet worden opgelost, omdat front-end optimalisatie die wordt toegepast op een trage oorsprong teleurstellende resultaten oplevert die vervolgens ten onrechte worden toegeschreven aan de optimalisatie.
Switas zoals gezien op
