Als website- of webserviceprovider zijn uw KPI’s (Key Performance Indicators) van levensbelang. In dit artikel definiëren we die KPI’s en helpen u beslissen welke tools u nodig hebt om de KPI’s die belangrijk voor u zijn te monitoren en te volgen.
De KPI’s die belangrijk voor u zijn worden vaak geassocieerd met de afdeling waar u werkt. DevOps geeft om performance- en uptime-KPI’s, marketing besteedt meer aandacht aan de acquisitie, bounce- en conversiepercentages, en het User Experience (UX)-team geeft meer om functionaliteit en gebruiksgemak. Hoewel alle verschillende statistieken belangrijk zijn, moeten alle teams zich eerst en vooral bezighouden met performance- en beschikbaarheids-KPI’s omdat die elk aspect van een website of service beïnvloeden.
Waarom zijn performance- en uptime-KPI’s van belang?
Slechte prestaties of frequente of langdurige uitval tasten de perceptie en het vertrouwen van de gebruiker aan. Studies hebben aangetoond dat een vertraging van een halve seconde de mening van de gebruiker over de website aanzienlijk negatiever kan maken en zelfs hun gevoelens over de pagina-esthetiek kan beïnvloeden.
Siteproblemen zoals traag ladende pagina’s, slecht werkende webapplicaties en downtime hebben problemen die verder gaan dan het directe probleem. Sites met problemen ondervinden ook lagere rankings in zoekmachines, hogere bouncepercentages, een hoger percentage verlaten winkelwagens, verminderde gebruikersbetrokkenheid/-retentie en verminderde klanttevredenheid. Dus als u een SaaS-provider, e-commercesite of een website voor contentmarketing bent, moet u uw KPI’s volgen en kennen.
Uptime- en beschikbaarheid-KPI’s
De eerste KPI’s waar u op moet letten, zijn die welke direct verband houden met beschikbaarheid. Of u nu een webservice, SaaS-product, contentmarketing of een e-commercesite aanbiedt, als uw gebruikers uw site niet kunnen bereiken of uw service niet kunnen gebruiken, bent u verloren.
Uptimepercentage en hoge beschikbaarheid
Uw uptime is een eenvoudige verhouding van uw daadwerkelijk beschikbare tijd gedeeld door de totale periode minus eventueel gepland onderhoud. SLA’s (Service Level Agreement) beloven in het algemeen 98% uptime (7,31 dagen downtime per jaar) tot 99,99% (52,60 minuten downtime per jaar). Normaal gesproken geldt: hoe dichter een SLA bij 100% komt (hoge beschikbaarheid), hoe hoger de kosten van de service voor de klant zijn.
SLA-compliance monitoren en documenteren
Met Uptrend’s SLA Monitoring kunt u de naleving van SLA’s in één oogopslag controleren. Eerst configureert u uw SLA-definities om drie belangrijke KPI’s vast te leggen.
- Uptime: stel uw vereiste uptimepercentage en uw grenswaardepercentage in
- Paginalaadtijd: de performancenorm die is overeengekomen
- Operator responstijd: dit is hoelang een fout onbedoeld kan optreden. Een operator logt in bij Uptrends en bevestigt dat zij op de hoogte zijn van het probleem en er aan werken.
U kunt meerdere SLA-definities gebruiken en toepassen en deze bekijken in uw SLA-dashboard. Wanneer een controleregel niet in overeenstemming is met een SLA, verschijnt deze rood in het rapport. Uptrends berekent en bewaart de data onafhankelijk van uw controleregeldetails, en u kunt een SLA-document maken om elke periode en elke controleregel weer te geven die u wilt.
Performance-KPIs
We hebben kort de paginalaadtijd-KPI aangestipt in de discussie over SLA’s. De SLA-tracking legt wel de paginalaadtijd vast, maar bevat niet de details en andere KPI’s waar u waarschijnlijk belang aan hecht, zoals tijd tot eerste byte of verbindingstijd.
Hieronder hebben we KPI’s op elementniveau en op paginaniveau. Veel van deze KPI’s zien er hetzelfde uit, maar het is echt wat ze vertegenwoordigen wat overwogen moet worden. Bijvoorbeeld, DNS-resolvetijd is voor een enkel element waarbij de DNS-duur betrekking heeft op de bestede tijd aan het vinden van adressen voor de hele pagina.
KPI’s voor webpaginaperformance: één request per keer.
Elk pagina-element heeft zijn eigen kosten in performance en de gecombineerde kosten voor de KPI’s van elk element dragen bij aan de totale pagina-KPI’s. Als u naar afzonderlijke elementen kijkt, kunt u probleem-URL’s en pagina-elementen zoals afbeeldingen en scriptbestanden identificeren.
U kunt deze KPI’s krijgen via Uptrends’ Controleregels voor webperformance. De controleregel Full Page Check (FPC) start een echte browser (kies uit Chrome, Internet Explorer, Firefox of Phantom JS). Vervolgens start de FPC de eerste request en volgt de controleregel de performance-KPI’s voor elke volgende pagina request.
U kunt de KPI’s per controle bekijken in uw Details van de controle-rapporten, of u gebruikt uw performancedashboards om te zien hoe uw KPI’s na verloop van tijd gemiddeld presteren. Eerst bekijken we de betekenis van deze KPI’s, hoe ze er in een watervalrapport uitzien en hoe ze na verloop van tijd gemiddeld presteren in lijngrafieken.
Resolvetijd
Het omzetten van een domeinnaam naar een IP-adres is de eerste stap bij het vormen van een TCP/IP-verbinding. Een trage resolvetijd kan een aanwijzing zijn dat:
- De URL is omgeleid en extra DNS lookups vereist,
- De primaire DNS overstelpt is, of
- De TTL (time to live) voor het adres te kort is ingesteld, waardoor de browser extra lookups uitvoert.
In het dashboard Full Page Check kunnen we de schommeling van de adres resolve snelheid over 24 uur bekijken. De grote piek in de onderstaande grafiek trad op toen resolvetijden gedurende 15 minuten omhoog sprongen met de langste resolvetijd van 2,6 seconden.
TCP connect
De TCP-verbindingstijd is inclusief de tijd die nodig is om de eerste IP-verbinding met een server tot stand te brengen inclusief de TCP connect en HTTPS handshake. Het optimaliseren van performance voor TCP connect is complex. Als u meer wilt weten, biedt O’Reilly een goed overzicht voor het optimaliseren van TCP performance.
Hieronder hebben we een lijngrafiek met 24-uur aan verbindingstijden. De middelste piek is het gevolg van een time-outfout in de verbinding.
HTTPS handshake
Als onderdeel van de TCP-verbinding is de HTTPS handshake de tijd die nodig is om een versleutelde verbinding tot stand te brengen met SSL/TLS. Om een beveiligde verbinding te maken presenteert de server eerst een certificaat dat de client accepteert, vervolgens wisselen de server en de client encryptiesleutels uit om beveiligde communicatie te vormen. Nadat de HTTPS-handshake is voltooid, kan de client de inhoud aanvragen.
In de onderstaande tegel kunt u zien dat de handshake een klein deel van de verbinding is dat doorgaans minder dan een microseconde duurt. De piek is te wijten aan dezelfde time-out als die in de vorige grafiek.
Verzendtijd
Zodra de client en de server een verbinding vormen, kan de client (de browser) de content opvragen (GET). De “verzendtijd” is de tijd die de client nodig heeft om de request te verpakken en in te voeren naar de server. De verzendtijd is meestal minder dan een microseconde. De grafiek is alleen een vlakke lijn op nul seconden, dus niet interessant om te laten zien.
Wachttijd
Zodra de browser een request verzendt, wacht de browser op een respons. De wachttijd is de tijd vanaf het verzenden tot de respons. Netwerklatency en serververwerking/responstijden beïnvloeden de wachttijd.
In de onderstaande grafiek waren de wachttijden zoals verwacht, maar de wachttijden schoten rond 14:00 uur omhoog met een aantal wachttijden van wel 7 seconden.
Ontvangsttijd
De tijd vanaf de eerste byte aan data tot de laatste byte aan data de browser bereikt, is de ontvangsttijd. De ontvangsttijd ligt vaak onder een enkele microseconde, maar voor grotere bestanden zoals afbeeldingen kan de ontvangsttijd aanzienlijk worden.
In de onderstaande grafiek zijn de pieken in ontvangsttijden het gevolg van elementen van derden (afbeeldingen en style sheets).
Alles samengebracht
Door alle KPI’s in één lijngrafiek te combineren, kunt u zien hoe de verschillende pieken elkaar kunnen beïnvloeden. In de onderstaande grafiek vallen pieken in verbindingstijd samen met langere wachttijden.
Dieper ingaan op de FPC-watervallen
Bij elke Full Page Check krijgt u een watervalrapport waarin u kunt zien welke elementen een probleem hebben en u kunt precies zien welk deel van de communicatie het probleem heeft. De waterval hieronder geeft een aantal van de lange ontvangsttijden (groene balken) weer die bijdragen aan de pieken in de bovenstaande ontvangsttijdgrafiek. De wachttijden zijn ook wat lang (blauwe balken).
Onder aan elke waterval krijgt u de totale tijd en de gemiddelde tijd voor elke maatstaf gecombineerd voor de pagina, samen met de gemiddelden.
Alle KPI’s op elementniveau bij elkaar opgeteld vormen onze KPI’s op paginaniveau. U kunt onze performancedashboards gebruiken om KPI’s op paginaniveau te krijgen op basis van gemiddelden van elke controleregel. Bovendien kunt u de performancedashboards gebruiken om de data van meerdere FPC-controleregels te combineren om performancedata op siteniveau te krijgen.
Met Real User Monitoring kunt u ook gedetailleerde KPI’s op siteniveau krijgen gebaseerd op verschillende gebruikersomgevingen.
KPI’s op siteniveau (en paginaniveau) van Real User Monitoring-data
Hierboven hebben we de KPI’s op elementniveau bekeken voor één pagina. Met Real User Monitoring (RUM) kunt u deze KPI’s op verschillende interessante manieren bekijken die kunnen leiden tot een aantal zeer gebruikersspecifieke optimalisaties.
Met RUM kunt u ervaringsdata rechtstreeks van uw gebruikers ontvangen terwijl ze uw site bezoeken. U krijgt data die u kunt sorteren op basis van de verschillende omgevingsvariabelen die de ervaring van elke gebruiker uniek maken. U kunt KPI’s op site- of paginaniveau sorteren en krijgen gebaseerd op:
- Apparaattype
- Besturingssysteem (en versie)
- Browsertype (en versie)
- Locatie (land, en in sommige gevallen staat of provincie)
Hoe werkt RUM?
Het is vrij eenvoudig. Eerst voegt u een nieuwe RUM-site toe. Ten tweede neemt u het gegenereerde kleine script, voegt dit toe tussen de HEAD-tags op de site en start de site opnieuw op. Ten derde bekijkt u die uitgebreide gebruikerservaringsdata.
Uptrends verzamelt en aggregeert de gebruikersdata en maakt deze bijna in real time beschikbaar voor u. Rangschik uw data zoals u wilt in uw RUM-dashboards.
Laadtijd-KPI’s
Uw laadtijd-KPI’s vertellen u hoe snel uw server op een request reageert en hoelang het duurt om de pagina te downloaden en weer te geven. Deze KPI’s vertellen u hoe uw gebruiker de pagina heeft ervaren met betrekking tot het laden van pagina’s.
In de onderstaande tabel bekijken we de laadtijd-KPI’s op basis van de gebruikte apparaattypes. De categorie “Overige” bevat apparaten die minder vaak worden gebruikt. Door te klikken, kunt u inzoomen en zien om welke apparaten het gaat bij “overige”. In dit geval bestaat deze categorie uit tv’s (tv’s lijken het niet zo goed te doen met deze site).
U kunt zien dat de site het goed doet voor desktopgebruikers, maar andere apparaten moeten veel langer wachten op hun content.
U ziet dat de tijden die als laadtijd worden gerapporteerd niet de som zijn van tijd tot eerste byte en paginagereedtijd. Uptrends berekent deze waarden onafhankelijk van elkaar op basis van de mediaanwaarden, en de tijd tot eerste byte is feitelijk een deel van de weergegeven tijd voor de paginagereedtijd.
Time to first byte (TTFB)
Bij een request voor een bron door een gebruiker is de tijd vanaf de request tot de browser de eerste byte aan data ontvangt de tijd tot eerste byte. Een lange tijd tot eerste byte is een signaal dat de respons van de server traag is of dat netwerklatency een probleem vormt voor de locatie en het verbindingstype van de gebruiker.
Paginagereedtijd
De paginagereedtijd is de totale tijd die nodig is om de pagina volledig weer te geven met inbegrip van alle interactieve elementen.
KPI’s voor netwerkperformance
Uw netwerkduur is de combinatie van de redirect, DNS en verbindingstijden.
In dit voorbeeld kijken we naar besturingssystemen (zie hieronder). U ziet het vergrootglaspictogram naast elk item. Door op het pictogram te klikken, kunt u inzoomen om uitgesplitste data te bekijken op basis van de versie van het besturingssysteem.
Redirect performance
Als uw site requests van gebruikers doorstuurt van de ene naar de andere URL, voegt u tijd toe aan de verbinding. Hoewel redirects geen grote invloed op uw paginaperformance hebben, kunnen redirects wanneer zij een keten worden (een redirect naar een pagina die ook een redirect heeft) ernstige vertragingen toevoegen. Door de duur van de redirect in de gaten te houden, kunt u op de hoogte blijven indien en zodra redirects een probleem worden.
In de voorbeelddata hierboven kunt u zien dat redirects bijdragen aan veel extra verbindingstijd vanwege de tijd die aan redirects is besteed. De desktopversies van de besturingssystemen hebben helemaal geen tijd besteed aan redirects, maar redirects kosten veel tijd bij sommige mobiele besturingssystemen.
DNS-Performance
Zoals eerder besproken, is de DNS resolve de tijd die nodig is om het IP-adres op basis van een domeinnaam te krijgen. De meeste pagina’s hebben inhoud die afkomstig is van meerdere unieke URL’s, en elke unieke URL vereist zijn eigen resolve. De DNS-duur is de gecombineerde tijd die nodig is voor de resolve van de URL’s van de pagina’s.
In het bovenstaande voorbeeld hebben mobiele gebruikers langere resolvetijden vanwege de redirects voor mobiele gebruikers.
Verbindingsperformance
Verbindingsduur is de tijd die nodig is om een verbinding te voltooien tussen de client en de server. De verbindingsduur omvat de HTTPS handshake en de TCP connect.
In ons voorbeeld hierboven blijven de verbindingstijden kort op minder dan een microseconde, Android en iOS uitgezonderd.
Backend performance
De backend duur omvat de tijden voor het verzenden en ontvangen van informatie, maar niet de tijd om de content te verwerken en te laden. In het onderstaande voorbeeld ziet u de backend duur op basis van de locaties van de gebruikers. Bij de landen met een vergrootglas kunt u inzoomen op data op staat-/provincieniveau.
Verzend performance
De verzendduur is de tijd die nodig is om de data van de client naar de server te verpakken en te verzenden. Natuurlijk geldt hoe meer data door de client moeten worden verzonden, hoe langer de verzendduur. De traagste verbinding tussen de client en een server bepaalt de totale tijd voor het verzenden van de data.
Ontvangst performance
De ontvangstduur is de tijd die nodig is om data van de server naar de client te verzenden. De ontvangsttijd is recht evenredig met de hoeveelheid verzonden data en de verbindingssnelheid. De traagste verbinding resulteert in de totale tijd voor de ontvangstduur.
Frontend Performance
De frontend duur is de gecombineerde tijd voor het parseren en laden van het DOM (Document Object Model) met de tijd om de content voor de pagina weer te geven.
In het onderstaande voorbeeld ziet u de frontend duur zoals ervaren met verschillende browsers. Als u inzoomt, kunt u de frontend duur op basis van de gebruikte browserversie weergeven.
DOM Performance
Elke request resulteert in toegevoegde content, en de browser verwerkt die content bij ontvangst. De browser gebruikt de gecombineerde responses om het DOM (Document Object Model) te construeren. Zodra de browser het DOM heeft gemaakt, kan het weergeven beginnen. De DOM-duur is de hoeveelheid tijd die de browser nodig heeft om de HTML (inclusief scripts en CSS-bestanden) tot een DOM te verwerken.
Render performance
De weergaveduur is de tijd die de browser nodig heeft om de DOM-inhoud te nemen en deze op het scherm weer te geven. De browserduur is een directe meting van de verwerkingssnelheid van de browser.
Download performance
De downloadtijd is de totale tijd die nodig is om de content aan te vragen, te ontvangen, te verwerken en weer te geven. De downloadtijd eindigt wanneer de browser aangeeft dat het DOM voor de pagina volledig is geladen.
De interactieve kaart hieronder toont de downloadtijd per land. Als u op een land klikt, gaat u naar een nieuw dashboard dat specifiek is voor dat land.
Kernpunten
- Website- en webserviceperformance en KPI’s voor uptime zijn over de hele linie essentieel voor alle afdelingen: ontwikkeling, systeembeheer, marketing en verkoop.
- Frequente of langdurige uitval vernietigt het vertrouwen van gebruikers in het merk.
- Als u een SLA bij een provider hebt of er een aan uw klanten aanbiedt, hebt u SLA-monitoring nodig om naleving of niet-naleving aan te tonen.
- Synthetic en Real User Monitoring zijn essentieel voor het volgen van KPI’s voor performance en uptime.
Geef een antwoord