Third-party content en hoe het van invloed is op de prestaties van je site

De laadtijd van pagina’s wordt beïnvloed door een aantal factoren. Het aantal HTTP-verzoeken (van browser naar webserver) voor het ophalen van subresources als CSS, JavaScript en afbeeldingen, en de omvang ofwel de bestandsgrootte van deze subresources zijn van invloed. Dit zijn echter niet alleen subresources van de site zelf (‘first-party’ content), maar ook subresources van derden, ofwel third-party content.

Het aandeel van third-party content varieert per site of pagina, maar kan in sommige gevallen wel 75% van het totale aantal subresources vormen. Vooral sites van uitgevers bestaan voor een groot deel uit third-party content, met name omdat advertenties een belangrijke inkomstenbron vormen. Gevolg is een langere laadtijd en daardoor een verslechterde user experience. Voor sommige bezoekers is dit een reden om een ad- of contentblocker te gebruiken om de leeservaring van content waarvoor ze een site bezoeken (critical content: relevante content) te verbeteren.

Het gebruik van third-party content vormt voor site-eigenaren vaak toegevoegde waarde omdat deze content helpt omzet te genereren (advertenties), conversies toe laten nemen (remarketing, a/b testing, personalisatie), content te laten delen door bezoekers (social sharing plug-ins) en inzicht biedt in het gedrag van bezoekers (analytics trackers). Third-party content is dus van belang voor de business. Het is een vast gegeven dat deze subresources deel uitmaken van elke webpagina en invloed hebben op de user experience.

Critical content

Maar in hoeverre is deze third-party content noodzakelijk voor de weergave van kritieke content? Dit is vaak het geval bij a/b testing en personalisatie. Dit type third-party content beïnvloedt niet alleen de totale laadtijd, maar ook de rendering ofwel weergave van critical content (boven de vouw) wordt er door vertraagd. Resultaat is dat het langer duurt voordat de content boven de vouw door de browser wordt weergegeven en de laadtijd zoals die door gebruiker wordt ervaren, langer wordt.

Toepassing van een aantal third-party bronnen waardoor de weergave van de pagina wordt vertraagd.

Subresources van derden die een pagina verrijken maar niet noodzakelijk zijn voor de weergave of functionaliteit van de pagina, dienen op een later moment, na de weergave van kritieke content, geladen te worden. Hoewel deze subresources dan alleen invloed hebben op de totale laadtijd, vormen ze qua bandbreedte wel concurrentie voor first-party subresources wanneer de third-party subresources groot van omvang zijn. Voor gebruikers van smartphones op een 3G-verbinding kan het laden van first-party subresources flink vertraagd worden door het laden van third-party subresources.

Wanneer servers van derden door de geografische afstand of door onvoldoende performance niet in staat zijn snel op verzoeken van de browser te reageren, zal de laadtijd toenemen. En mocht de server helemaal niet reageren (outage) dan is vaak niet bekend wat de uitwerking hiervan (single point of failure) is op de weergave of functionaliteit van de pagina. Het merendeel van third-party providers zoals adservers, trackers en widgets maken gebruik van JavaScript die weergaveblokkerend is. Wanneer er bij deze third-party providers sprake is van performance problemen zoals lange reactietijd van de server of zelfs downtime, dan zullen bezoekers van de site hier vaak ook de problemen (weergave en/of functionaliteit van de pagina) van ondervinden.

De uitvoering van third-party scripts heeft ook impact op de performance van een pagina zelf. Processors van smartphones worden zwaar belast met het verwerken van grote of complexe scripts waardoor de User Interface wordt vertraagd (janking). Denk hierbij aan pagina’s die niet vloeiend scrollen of waarvan animaties (bijvoorbeeld een een fotoslider) schokkerig verlopen omdat de browser niet direct op touch input van de gebruiker kan reageren.

Third-party subresources voeren vaak weer fourth- of fifth-party verzoeken uit voor andere noodzakelijke subresources (meestal scripts). Ook dit beïnvloedt de laadtijd doordat extra DNS lookups vereist zijn (verzoek bij ander domein of host) en er sprake is van TCP slow start, SSL-handshakes, reactietijd van de server i.v.m. processing, eventuele redirects en het downloaden en uitvoeren van de subresources zelf.

Beleid voor third-party content

Het toepassen van third-party content kan dus van grote invloed zijn op de user experience van een site. Het is daarom belangrijk om hier kritisch mee om te gaan en een beleid voor toepassing van third-party bronnen te hanteren. Dit beleid zal antwoorden op vragen moeten opleveren als:

• Welke third-party resources geladen mogen worden;
• Waar deze bronnen aan moeten voldoen (omvang, maximaal aantal requests, volgorde van laden, SLA, en andere technische randvoorwaarden);
• Hoe om te gaan met toevoeging van nieuwe third-party bronnen;
• Wat de maximale verhouding tussen first- en third-party content mag zijn.

Hoe kunt u het gebruik van third-party content optimaliseren? Onderstaande acties helpen te bepalen of toepassing noodzakelijk is en of de inzet efficiënter kan. Dit geldt zowel voor bestaande third-party content als nieuwe bronnen waarvan overwogen wordt deze toe te passen binnen de site.

• Beoordeel de relevantie en het gebruik van third-party content. Vaak kan de ROI de doorslag geven of het zinvol is de inzet wel of niet te handhaven. Bereken de impact van de third-party content door de laadtijd van de pagina te meten met en zonder de betreffende third-party subresources. Bereken het verlies of winst in conversies door uit te gaan van The Aberdeen Group performance stats waar op basis van onderzoek is gebleken dat elke extra seconde laadtijd in een verlies van 7% aan conversies resulteert. Verreken dit resultaat met de verwachte stijging in conversies die de inzet van de betreffende third-party content belooft.
• Wanneer een third-party provider niet (meer) wordt gebruikt, kan de tag vaak zonder problemen verwijderd worden. Dit wordt echter vaak vergeten, doe daarom onderzoek om het gebruik van third-party content op te schonen.
• Als de achterliggende technologie van third-party services wordt verbeterd waardoor deze minder van invloed is op het laden van de pagina, dient daarvoor vaak een vervangende tag geplaatst te worden. Steeds meer third-party content wordt beschikbaar gesteld via een asynchroon script dat geen impact heeft op de weergave van critical content. Het is dus nodig om hier zelf actie op te ondernemen en regelmatig de ontwikkelingen bij third-party providers te volgen.
• Laad third-party content alleen op pagina’s waar gebruik gemaakt wordt van deze services. Waarom zou u bijvoorbeeld scripts voor een A/B testing tool laden in een pagina waar nooit testen worden uitgevoerd?
• Ga na of third-party content die reeds in gebruik is ook voor andere doeleinden gebruikt kan worden. Dit kan verzoeken besparen omdat het script van een third-party provider meerdere services combineert.
• Indien alle bovenstaande acties zijn uitgevoerd en het gebruik van een third-party service noodzakelijk is, dan is het van belang het laadproces zo optimaal mogelijk in te richten.

Optimaliseren van laadtijden

Het optimaliseren van het laden van third-party subresources verschilt technisch gezien niet van eigen subresources. Het grootste verschil is echter dat u hier zelf geen controle over hebt en afhankelijk bent van de andere partij. Het is daarom belangrijk om na te gaan in hoeverre er technisch aan wordt voldaan. Gelukkig besteden steeds meer third-party providers aandacht aan de performance van hun product, en de impact daarvan binnen sites van klanten. Steeds vaker zien we dat dit wordt verwerkt in de documentatie op de site of dat third-party providers uitvoerig reageren bij navraag. Echter is deze informatie niet altijd correct, laat dit daarom altijd door een web performance optimalisatie expert beoordelen.

Om de laadtijd van pagina’s zo kort mogelijk te houden is het van belang:

• Het aantal requests (HTTP verzoeken) te beperken door deze te verwijderen of bestanden van hetzelfde bestandsformaat samen te voegen. Dit is te realiseren middels:
  • Het inschakelen van browsercaching;
  • Het samenvoegen van bestanden (CSS, JS, CSS image sprites) om het aantal HTTP-verzoeken te beperken.

Controleer of voor statische third-party subresources de geldigheid van browsercaching is ingeschakeld voor ten minste 24 uur. Hiermee wordt voorkomen dat de browser van bezoekers bij het laden van een volgende pagina in dezelfde sessie of bij een volgend bezoek, subresources van de server opvragen. Bij browsercaching worden deze subresources lokaal uit de browsercache geladen, wat sneller is omdat latency door het netwerk wordt voorkomen. Browsercaching is beschikbaar in verschillende vormen. Of browsercaching mogelijk is, is afhankelijk van de technische werking van de third-party service.

Die technische werking is vaak ook bepalend of een enkel request voldoende is om subresources te laden. Bij het laden van een externe videoplayer is het wenselijk dat de afbeeldingen voor de interface via CSS images sprites met maximaal één verzoek wordt geladen.

• Bestandsgrootte van statische bestanden te verkleinen door compressietechnieken toe te passen. Dit is te realiseren middels:
  • Het toepassen van gzip-compressie;
  • Het comprimeren van afbeeldingen;
  • Het minifyen van JS, CSS, HTML.

Gzip-compressie levert een grote winst op in het verkleinen van de bestandsomvang (van tekstuele bestanden als CSS, JS, SVG en HTML) waardoor de overdracht van data via het netwerk wordt verkleind. Inschakeling van deze feature wordt vaak vergeten of staat uit omdat dit soms impact heeft op de performance van de server wanneer deze veel verzoeken te verwerken heeft. Ga na of gzip-compressie is ingeschakeld voor alle subresources, of doe navraag waarom dit niet actief is en ingeschakeld kan worden.

Afbeeldingen (JPG, GIF, PNG) dienen altijd gecomprimeerd te worden en gzip-compressie heeft nog meer effect wanneer tekstuele bestanden via een minifier zijn verkleind door deze bestanden te ontdoen van lege ruimte, commentaar en naamgeving in scripts die voor computers veel korter kan zonder de werking ervan te verliezen.

• De volgorde waarin bestanden aangeroepen worden te optimaliseren om daarmee de weergave (het renderen) van de pagina te verbeteren. Dit is te realiseren middels:
  • Het asynchroon laden van JavaScript, CSS

Indien third-party subresources niet noodzakelijk zijn voor de weergave van de pagina, is het zeer wenselijk om het laden van weergaveblokkerende bronnen als CSS en JavaScript uit te stellen tot een later moment na rendering van content boven-de-vouw (critical content). Dit is vaak niet wenselijk bij services als A/B testing en personalisatie omdat het asynchroon laden dan zal resulteren in een flickering effect wat als storend wordt ervaren of de test onbetrouwbaar maakt.

• De server verzoeken vanuit de browser snel te laten beantwoorden zodat de browser HTML direct kan downloaden en verwerken (parsen), en weergave van content boven de vouw snel van start kan gaan

Controleer vanaf welke geografische locatie de subresources worden geladen. Ligt deze locatie dicht in de buurt van bezoekers van de site? Veel third-party content wordt tegenwoordig steeds vaker via een Content Delivery Network (CDN) aangeboden. Het laden vanaf een CDN beperkt de latency die ontstaat door fysieke afstand tussen server en gebruiker. Het netwerk van een CDN bestaat uit servers op diverse geografische locaties zodat een bezoeker altijd een server aanspreekt die geografisch gezien dicht in de buurt ligt. Deze CDN servers hebben een kopie van statische bestanden in de cache opgeslagen en kunnen deze subresources daardoor snel aan de bezoeker serveren.

Er zijn op de markt veel verschillende partijen die CDN’s beschikbaar stellen, ze verschillen echter in prestaties en beschikbare locaties. Vraag na of onderzoek bij welke partij een CDN in gebruik is en of alle subresources wel via de CDN gedistribueerd worden en de locatie van de CDN-servers dicht in buurt van bezoekers van de site beschikbaar is.

Hoe kunt u dit zelf controleren?

Met Google PageSpeed Insights is te controleren of browsercaching actief is en de geldigheid lang genoeg is voor third-party subresources. Tevens kunt u met deze tool controleren of gzip-compressie en minification van het tekstuele bestand is toegepast. Daarnaast maakt de tool inzichtelijk of afbeeldingen voldoende gecomprimeerd zijn en of de volgorde van laden van subresources de rendering van content boven de vouw niet nadelig beïnvloedt.

p>Met WebPageTest kan onderzocht worden of er sprake is van vertragende factoren in het netwerk (DNS lookups, SSL-handshake) of de server (reactietijd, redirects). Tevens biedt deze tool inzicht in het aantal verzoeken, bestandsgrootte, gzip-compressie, browsercaching en compressie van afbeeldingen. Daarnaast maakt WebPageTest ook inzichtelijk welke subresources vanaf een bekende CDN worden geladen, en kunt u zien welke subresources weergaveblokkerend zijn. Via de SPOF-tab in WebPageTest kan gecontroleerd worden wat de impact is op de weergave en functionaliteit van een pagina indien een third-party subresource niet geladen kan worden.

Om inzichtelijk te maken of er sprake is van fourth- en fifth-party requests, etc. kunt u de test van WebPageTest toepassen in Request Map. Dit is een tool om visueel in kaart te brengen waar en hoeveel verzoeken naar third-party providers worden uitgevoerd.

Een visuele weergave van alle 249 requests uitgevoerd door de homepage van nytimes.com, gegenereerd via de tool Request Map

Security

Met de implementatie van third-party bronnen hebben third-party providers technisch gezien de vrijheid om elke vorm van content op elke pagina te publiceren waar de tag beschikbaar is. Uiteraard zal dit niet de bedoeling zijn van deze providers, maar door een bug in de software of een hack van de server kan er onbedoeld toch ongewenste malware, phising of virussen of niet-functionerende content zoals surveys of widgets gepubliceerd worden. Dit is niet volledig uit te sluiten en kan ook door een menselijke fout worden veroorzaakt. Ook kan het gebeuren dat de uitvoering van een third-party script conflicteert met eigen scripts of die van andere third-party providers. Wees hiervan bewust, ga na welke issues in het verleden hebben plaatsgevonden en hoe de betreffende partijen hier mee omgaan en nog belangrijker: hoe het in de toekomst voorkomen wordt.

Wat kunt u verder doen?

Maak gebruik van een Tag Management Systeem zoals Google Tag Manager. Met deze software kunt u eenvoudig third-party content laden waarbij u tevens kunt bepalen op welke pagina’s dat gebeurt en op welk moment tijdens het laden van de pagina third-party content wordt geladen. Google Tag Manager laadt third-party content standaard asynchroon. Dit voorkomt dat third-party content niet van invloed is op de rendering van content boven de vouw. Dit is echter niet wenselijk voor alle third-party services zoals bijv. client-side a/b testing tools omdat de uitvoering daarvan niet altijd tot z’n recht komt. Tag management software biedt de site-eigenaar de mogelijkheid om bij problemen of drukte op de site third-party content (tijdelijk geautomatiseerd) uit te schakelen op de hele site of binnen bepaalde delen.

Bij het gebruik van Tag Management Systemen schuilt wel het gevaar dat het toevoegen van third-party content ook uitgevoerd kan worden door mensen in de organisatie die zich niet bewust zijn van de impact. Sites die gebruikmaken van Google Tag Manager blijken meer content van verschillende domeinen te bevatten, dan sites die geen gebruikmaken van deze software. Daarom is het ook hier weer belangrijk een beleid voor third-party content te voeren.

Monitor de performance van de site door gebruik te maken van Real User Monitoring. Met dit type tool wordt de ervaren performance van elke gebruiker vastgelegd. Daarmee is het ook mogelijk om de performance van third-party content te monitoren. Dit biedt de mogelijkheid om de SLA van third-party content te herzien of feedback te geven aan third-party providers/vendors omdat deze wellicht niet van een issue op de hoogte zijn.

Verder is het belangrijk de implementatie van third-party content te testen (voorkom bijv. JavaScript errors) op zoveel mogelijk devices en browsers die gebruikt worden door bezoekers van de site. Google Analytics biedt inzicht op welke devices en browser de focus dient te liggen.

Conclusie

Third-party content is aanwezig binnen elke site, maar de omvang van verzoeken en bestandsgrootte verschilt per site of pagina. De impact van third-party content op de prestaties van een site wordt vaak over het hoofd gezien. Er wordt bij het toevoegen van third-party content meestal niet stilgestaan bij wat de invloed is op de laadtijd en user experience van pagina’s.

Third-party content vertraagd het laden van pagina’s en soms wordt de browser ook belemmerd in het weergeven van content boven de vouw. Om dit zoveel mogelijk te voorkomen is het zinvol een beleid voor third-party content door te voeren en na te leven.

Met dit beleid is het mogelijk te bepalen of toepassing van third-party services noodzakelijk is en of de inzet efficiënter kan. Dit geldt zowel voor bestaande third-party content als nieuwe bronnen waarvan overwogen wordt deze toe te passen binnen de site. Indien inzet van een third-party service wenselijk is voor de business zal de impact op de performance van de site minimaal moeten zijn. Onderzoek dit eerst en overleg met third-party providers over de punten waarop dit beter kan.