Als er na het lezen van de bovenstaande artikelen nog steeds een moeilijk te verklaren verschil bestaat tussen het aantal klikken en sessies, wordt dit mogelijk veroorzaakt door de latentie. Problemen met klikken en sessies waarbij de latentie een rol speelt, hebben doorgaans de volgende kenmerken:
- Het verschil tussen klikken en sessies kan niet worden herleid tot een specifieke campagne, een specifieke advertentiegroep of een specifiek zoekwoord.
- U ziet bij alle actieve Google Ads-campagnes dat het aantal sessies altijd minder is dan het aantal klikken.
- Als u segmenteert op apparaat, bijvoorbeeld op desktop, tablet of mobiel, ziet u een verschil dat zich voordoet bij meerdere platformen.
In dit artikel vindt u informatie over het volgende:
- Waarom het belangrijk is om snel te zijn
- Positie is belangrijk
- Gevolgen van traagheid
- Een kortetermijnoplossing voor korte klikken
- Hoe weet ik of mijn website langzaam is?
- Hoe kan ik mijn website sneller maken?
- Omleidingen verwijderen of bestemmings-URL's updaten
- CSS-sprites
- Een netwerk voor het leveren van content gebruiken
- HTML-, CSS- en JS-bestanden comprimeren
- Populaire pagina's in het cachegeheugen opslaan
- Ajax en plug-ins zoals Infinite Scroll of Lazy Load voor Jquery gebruiken
- Gzip-compressie
- Upgraden naar Universal Analytics
- Een snellere webhostingserver
- Meer tips en suggesties
Waarom het belangrijk is om snel te zijn
Internetgebruikers zijn over het algemeen niet erg geduldig. Dit blijkt uit onderzoeken zoals dat van KissMetrics, waarbij een aantal ontnuchterende conclusies werd getrokken. Zo staat er in dit onderzoek: "Een vertraging van één seconde in de reactie van een pagina kan resulteren in 7% minder conversies" en "47% van de consumenten verwacht dat een webpagina in twee seconden of minder wordt geladen".
Wat betekent dit voor u? Als uw website te langzaam wordt geladen, bestaat de mogelijkheid dat gebruikers deze verlaten en naar uw concurrenten gaan. Dit geldt met name als uw concurrenten dezelfde content snel kunnen leveren.
Positie is belangrijk
We krijgen vaak de vraag waar de Analytics-trackingcode in de HTML-bron van een pagina moet worden geplaatst. Het antwoord hierop is afhankelijk van hoe nauwkeurig u bouncende bezoekers wilt bijhouden. Als een klik plaatsvindt en het enkele seconden duurt totdat een sessie wordt vastgelegd, bestaat er een grote kans dat een dergelijke sessie in sommige gevallen niet wordt bijgehouden. Over het algemeen raden we aan om de trackingcode pal voor de afsluitende </head>-tag te plaatsen.
Gevolgen van traagheid
Korte klikken: een korte klik vindt plaats wanneer een gebruiker op een advertentie klikt, maar op de knop 'Vorige' klikt of de browser afsluit voordat het verzoek om de Analytics-trackingcode kan worden geactiveerd. De klik wordt dan wel vastgelegd in Google Ads, maar er wordt in Analytics geen bijbehorende sessie vastgelegd.
Over het algemeen is het zo dat hoe langzamer de website reageert en hoe groter het aantal verzoeken is dat vóór het Analytics-fragment staat, des te groter de kans dat u te maken krijgt met korte klikken en ontbrekende sessiegegevens.
U kunt korte klikken ook zien als daadwerkelijke gebruikers die van uw website bouncen. Dit betekent dat als u deze bouncesessies niet bijhoudt, uw bouncepercentage kunstmatig laag kan zijn.
Mobiele en korte klikken: mobiele apparaten werken doorgaans in een langzamere netwerkinfrastructuur (3G-netwerken) dan de meeste desktopverbindingen (ADSL/kabel). Als u target op mobiele apparaten, is een snel reagerende website dus nog belangrijker om korte klikken te voorkomen.
Een kortetermijnoplossing voor korte klikken
Als kortetermijnoplossing voor korte klikken kunt u proberen om het Analytics-trackingfragment zo hoog mogelijk in de HTML-bron te zetten. Het beste is om het fragment vóór alle andere JavaScript-bestanden te plaatsen.
In het bovenstaande screenshot ziet u dat er verschillende JavaScript-bestandsverzoeken moeten plaatsvinden (synchrone tags), voordat het Analytics-trackingfragment kan worden uitgevoerd. Optimalisatietechnieken komen later aan bod, maar als kortetermijnoplossing kunt u het Analytics-trackingfragment voorlopig vóór de andere JavaScript-bestanden zetten. U hoeft zich geen zorgen te maken dat uw pagina langzamer wordt weergegeven door Analytics. Er wordt namelijk een asynchrone JavaScript-tag gebruikt, wat betekent dat uw pagina ook wordt weergegeven als de Analytics-server traag reageert.
De reden waarom dit een tijdelijke oplossing is, zit hem in het feit dat u hiermee sessies kunt vastleggen die anders zouden ontbreken wanneer gebruikers uw pagina vroegtijdig verlaten (omdat het Analytics-fragment niet eerder wordt uitgevoerd). Op de lange termijn wilt u natuurlijk de gebruikers die nu nog bouncen, op uw website zien te houden. Hiervoor moet u het onderliggende probleem oplossen, oftewel de traag reagerende website.
Hoe weet ik of mijn website langzaam is?
Zoals hierboven staat vermeld, werkt het tot op zekere hoogte om uw Analytics-trackingcode hoger in de HTML-bron te zetten. Het is echter ook van belang dat uw website sneller reageert.
Maar hoe weet u of uw website langzaam is?
Test 1
Zorg dat het cachegeheugen van de computer leeg is. Als dit nog niet het geval is, wis dan eerst het cachegeheugen en de cookies op de computer. Open vervolgens een nieuw tabblad in Chrome en geef de bestemmings-URL op in de adresbalk van de browser. Open 'Hulpprogramma's voor ontwikkelaars' in Chrome en ga naar het netwerktabblad.
Laad de website en bekijk de lijst met verzoeken. Deze ziet er ongeveer als volgt uit:
Zoek naar _utm.gif (Classic Analytics) of 'collect' (Universal Analytics) en bekijk de tijdlijnsectie rechts. In de bovenstaande illustratie ziet u dat het ongeveer 8 seconden duurde vanaf het moment dat het eerste verzoek werd uitgevoerd (waarbij er een klik werd vastgelegd) tot het Analytics-verzoek werd uitgevoerd (waarbij er een sessie werd vastgelegd).
Als een gebruiker tijdens deze 8 seconden op de knop 'Vorige' klikt, wordt er in Analytics mogelijk geen sessie op deze website vastgelegd terwijl er in Google Ads wel een klik is geregistreerd.
Denk nog eens aan het citaat van KissMetrics: "De helft van de gebruikers verwacht dat een pagina in twee seconden of minder wordt geladen". Deze website is dus voor verbetering vatbaar.
Test 2
In Analytics worden gegevens over de laadtijden van pagina's automatisch vastgelegd in de rapporten over sitesnelheid.
In deze rapporten kunt u zien hoe specifieke bestemmings-URL's voor Google Ads presteren als het gaat om de latentie. In dit voorbeeld zien we dat de snelheid voor deze specifieke URL rond de 25 seconden ligt, wat heel langzaam is.
Is het u opgevallen dat het bouncepercentage van deze pagina ook hoog is? Deze bestemmings-URL genereert dus veel korte klikken (oftewel bounces) en de klikken die wel worden vastgelegd hebben ook een hoog bouncepercentage. Dit is natuurlijk niet goed.
De laadtijd van een pagina moet idealiter tussen de 3 en 4 seconden liggen.
Hoewel deze rapporten voor sitesnelheid doorgaans een goede indicatie geven van de laadtijden van pagina's, is de steekproef standaard gebaseerd op slechts 1% van het verkeer. Als uw site dagelijks een relatief klein aantal bezoekers trekt, bijvoorbeeld 100.000 of minder, is het een goed idee om het steekproefpercentage te verhogen, bijvoorbeeld naar 5%. Hierdoor komen de de laadtijden van pagina's en andere statistische gegevens over de sitesnelheid beter overeen met de werkelijkheid.
Houd er rekening mee dat er dan nog een verzoek wordt gemaakt. In bijna alle gevallen heeft dit echter geen negatieve invloed op de gebruikerservaring.
Hoe kan ik mijn website sneller maken?
De rapporten over sitesnelheid van Analytics leveren nu ook sitesnelheidsuggesties. Geef de bestemmings-URL's op waarop het meest wordt geklikt om suggesties te zien over hoe u deze pagina's sneller kunt maken.
Omleidingen verwijderen of bestemmings-URL's updaten
Zelfs als de Google Ads-parameter voor autotagging blijft staan in uw omleidingen en deze parameter wordt doorgegeven aan de uiteindelijke bestemmings-URL, zorgen omleidingen voor extra latentie tussen de klik en het moment dat de sessie door Analytics kan worden vastgelegd.
In sommige gevallen hebben site-eigenaren meerdere omleidingen tussen de Google Ads-klik en de uiteindelijke bestemmings-URL.
U moet uw bestemmings-URL voor Google Ads updaten, zodat hierin de uiteindelijke bestemmings-URL wordt vermeld en er geen omleidingen zijn.
Soms gebruiken klanten een tussenliggende service, zoals een klikserver die Google Ads-klikken vastlegt. Dit soort services wordt doorgaans gebruikt door externe rapportageplatformen.
Hoewel we begrijpen dat u in meerdere platformen wilt rapporteren, kunnen dit soort services fungeren als knelpunt en resulteren in een langere laadtijd. Als u moeilijkheden heeft met het aantal klikken en sessies dat in Analytics wordt vastgelegd, raden we u aan deze service voor het bijhouden van klikken tijdelijk te verwijderen. Als u ziet dat de verhouding tussen het aantal klikken en sessies hierdoor verbetert, kunt u wellicht beter stoppen met het gebruik van het betreffende externe platform of op zoek gaan naar een andere aanbieder die sneller is.
CSS-sprites
CSS-sprites kunnen meerdere afbeeldingsverzoeken vervangen.
U ziet dat de website in de bovenstaande illustratie meerdere afbeeldingsverzoeken (.png-bestanden) bevat naar kleine pictogrammen en afbeeldingsbestanden. Het voordeel van CSS-sprites is eenvoudig: in plaats van meerdere afbeeldingsverzoeken te gebruiken, plaatst u al deze afbeeldingen in één verzoek (een grotere afbeelding). Vervolgens gebruikt u CSS om aan te geven in welke gedeelten van uw website de delen van de afbeelding moeten worden weergegeven. Eén groot afbeeldingsverzoek is sneller dan meerdere kleine afbeeldingsverzoeken.
Een netwerk voor het leveren van content gebruiken
Een netwerk voor het leveren van content is een geweldige manier om uw website sneller en tegelijkertijd beter schaalbaar en betrouwbaarder te maken. Een dergelijk netwerk distribueert de veelgebruikte bestanden en content van uw website en plaatst ze op meerdere servers over de hele wereld.
Normaal gesproken bevindt een webhostingservice zich op een vaste fysieke locatie, bijvoorbeeld in Amsterdam. Dit is prima voor gebruikers in Nederland, want zij zullen de content van uw website snel ontvangen. Maar hoe zit het met gebruikers uit Amerika of Australië? Zij zullen te maken hebben met een langere latentie omdat de bestanden helemaal in Amsterdam staan. Als u een netwerk voor het leveren van content gebruikt, ontvangen deze gebruikers de bestanden via een server die zich dichter bij hun fysieke locatie bevindt.
Wanneer u uw website over meerdere servers over de hele wereld distribueert, heeft u ook minder last van storingen en andere infrastructuurproblemen.
Een netwerk voor het leveren van content werkt uitstekend voor content die over het algemeen statisch blijft of niet vaak verandert, zoals uw JavaScript-bestanden, CSS, HTML, afbeeldingen en videocontent. Een dergelijk netwerk maakt deze bestanden tevens zo klein mogelijk, door alle witregels uit JavaScript-, CSS- en HTML-bestanden te verwijderen.
Google heeft zijn eigen netwerk voor het leveren van content, namelijk Google PageSpeed.
HTML-, CSS- en JS-bestanden comprimeren
Het kan zijn dat u geen netwerk voor het leveren van content (zoals hierboven besproken) wilt gebruiken. Als dat het geval is, zijn er nog steeds verschillende modules, plug-ins en gratis webservices beschikbaar die automatisch content voor u comprimeren door witregels te verwijderen en meerdere bestanden (zoals CSS-bestanden) te bundelen in één verzoek.
Populaire pagina's in het cachegeheugen opslaan
Webserverstacks maken vaak gebruik van Linux Apache MySQL PHP (LAMP).
In het bovenstaande diagram zien we dat er meerdere stappen nodig zijn om een HTML-pagina weer te geven aan een gebruiker.
- De webserver ontvangt het verzoek.
- De webserver verzendt het verzoek vervolgens via PHP. Aan de hand hiervan wordt bepaald tot welke bestanden of databaserijen toegang nodig is.
- PHP maakt hier een pakket van en stelt de betreffende HTML-pagina samen, die vervolgens aan de gebruiker wordt geretourneerd.
Hoe caching kan helpen
In veel gevallen is de content van uw pagina niet gewijzigd als een gebruiker een pagina opnieuw opent, bijvoorbeeld de pagina met veelgestelde vragen. Het is dan niet nodig om het hele proces in het bovenstaande diagram te doorlopen. De pagina kan één keer worden samengesteld en worden opgeslagen in het cachegeheugen als tijdelijk HTML-bestand. Hierdoor hoeft de webserver niets steeds de pagina opnieuw te genereren via PHP en herhaaldelijk query's uit te voeren op een database. In plaats hiervan wordt er aan de meeste gebruikers dan een statisch HTML-bestand getoond. De webserver hoeft dan niet aldoor te multitasken en uw website wordt voor iedereen sneller.
Er zijn verschillende gratis modules verkrijgbaar die deze taak voor uw website kunnen uitvoeren.
Hoewel in het voorgaande voorbeeld PHP werd genoemd, werken veel andere webservers volgens een soortgelijk principe. De kans is groot dat er ook voor deze webservers vergelijkbare modules verkrijgbaar zijn waarmee u pagina's in het cachegeheugen kunt laten opslaan.
Ajax en plug-ins zoals Infinite Scroll of Lazy Load voor Jquery gebruiken
Is het u weleens opgevallen dat sommige websites content laden terwijl u naar beneden scrolt? YouTube doet dit voor thumbnails van gerelateerde video's. Het gedeelte met reacties is beperkt tot de eerste paar resultaten, tenzij u aangeeft dat u meer reacties wilt weergeven.
Als u dergelijke technieken op de juiste manier gebruikt, kunt u de paginagrootte in het aanvankelijke verzoek beperken en gebruikers onmiddellijk interactief met uw pagina's laten zijn. Wanneer gebruikers meer content willen zien, kunnen ze verder scrollen waardoor er meer items worden geladen.
U moet rekening houden met verschillende zaken met betrekking tot het gebruiksgemak en de toegankelijkheid wanneer u een dergelijke oplossing implementeert. Raadpleeg de documentatie van LazyLoad en Infinite Scroll voor meer informatie.
Gzip-compressie
Oudere webbrowsers bieden geen ondersteuning voor deze vorm van paginacompressie (HTML, CSS, JavaScript, etc.), maar nieuwere browsers wel (waaronder browsers op mobiele apparaten). Het handige van deze functie is dat u deze al met één druk op de knop kunt gebruiken.
Bekijk deze video voor meer informatie over Gzip.
Upgraden naar Universal Analytics
Als u Classic Analytics (ga.js) nog niet heeft geüpgraded naar Universal Analytics (analytics.js), is het misschien nu tijd om te migreren naar het nieuwste Analytics-platform. U krijgt niet alleen toegang tot de nieuwste productfuncties, maar Universal Analytics bevat ook een aantal prestatieverbeteringen die de moeite waard zijn:
- Op modules gebaseerde bibliotheek met trackingcodes: analytics.js bevat niet langer externe modules, zoals Ecommerce, voor alle websites (wat wel het geval was in ga.js). Hierdoor is analytics.js kleiner als het gaat om bestandsgrootte, waardoor bestanden sneller kunnen worden overgedragen.
- Verminderde afhankelijkheid van cookies: in Universal Analytics worden campagne- en sessiegegevens op de server (in plaats van op de client) berekend, waardoor er bij ieder bestandsverzoek minder cookiegegevens worden overgedragen. Dit kan leiden tot een kleine maar merkbare prestatieverbetering.
Een snellere webhostingserver
U loopt misschien wel klanten mis als uw website traag is. Daarom is het de moeite waard om te overwegen naar een snellere webhostingserver over te stappen.
Meer tips en suggesties
In dit artikel kunnen we niet alle optimalisatietechnieken bespreken, maar we willen u er wel op wijzen dat er nog vele andere technieken zijn. Raadpleeg deze documentatie voor meer tips en suggesties.
Houd er ten slotte rekening mee dat u de snelheid en reactietijd van uw eigen website wellicht kun verbeteren, maar dat u ook te maken kunt krijgen met gebruikers met een trage internetverbinding of een langzaam mobiel netwerk. Dit is meer een probleem in afgelegen en plattelandsgebieden en in ontwikkelingslanden met een beperkte of oude telecominfrastructuur.
Het beste wat u in dergelijke omstandigheden kunt doen is uw website zo snel mogelijk maken. Maar zelfs de best geoptimaliseerde websites kunnen last hebben van korte klikken als gevolg van een trage internetverbinding van gebruikers.
