Om du, när du läst ovanstående artiklar, fortfarande har avvikelser mellan klick och sessioner som är svåra att förklara, kan det bero på fördröjningar. Problem med klick och sessioner där fördröjning är en faktor har ofta följande egenskaper:
- Avvikelsen mellan klick och sessioner kan inte begränsas till en specifik kampanj eller annonsgrupp eller ett visst sökord.
- I alla aktiva Google Ads-kampanjer ser du ett mindre antal sessioner jämfört med antalet klick.
- Segmentering efter enhet, till exempel stationär dator, surfplatta eller mobil enhet, visar en avvikelse som finns på flera plattformar.
Innehåll i artikeln:
- Varför snabbhet är viktigt
- Positionering är viktigt
- Konsekvenser av långsamhet
- En kortsiktig lösning för korta klick
- Hur vet jag om webbplatsen är långsam?
- Hur kan jag göra webbplatsen snabbare?
- Ta bort omdirigeringar eller uppdatera måladresserna
- CSS-sprites
- Använd ett nätverk för innehållsleverans (NFI)
- Komprimera HTML-, CSS- och JS-filer
- Cachelagra populära begäranden
- Överväg att använda ajax och pluginprogram som Infinite Scroll eller Lazy Load för Jquery
- Gzip-komprimering
- Uppgradera till Universal Analytics
- Snabbare webbhotellsserver
- Fler tips och förslag
Varför snabbhet är viktigt
I allmänhet har användare på internet inte särskilt stort tålamod. Det framgår tydligt i undersökningar som exempelvis KissMetrics-studien där bland annat följande tillnyktrande slutsatser kunde dras: ”En fördröjning med en sekund på sidan kan orsaka 7 % minskning av antalet konverteringar.” och ”47 % av konsumenterna förväntar sig att en webbsida läses in på två sekunder eller mindre.”
Vad innebär det för dig? Om det tar för lång tid att läsa in din webbplats finns det en risk att användare lämnar webbplatsen och besöker dina konkurrenters webbplats istället, särskilt om konkurrenterna kan ge samma innehåll snabbt.
Positionering är viktigt
Vi får ofta frågan var Analytics spårningskod ska placeras i HTML-koden på en sida. Svaret är att det beror på hur exakta mätningar av antalet användare som lämnar sidan du vill göra. Om en användare klickar på en sida och det tar flera sekunder innan sessionen registreras är risken stor att en del av de här sessionerna inte spåras. I allmänhet rekommenderar vi att du placerar spårningskoden alldeles före sluttaggen </head>.
Konsekvenser av långsamhet
Korta klick: Ett kort klick är när en användare klickar på en annons och sedan klickar på bakåt-knappen eller stänger webbläsaren innan Analytics spårningskodsbegäran hinner aktiveras. Google Ads registrerar klicket, men en motsvarande session registreras inte i Analytics.
I allmänhet kan man säga att ju långsammare webbplatsen är på att svara och ju fler begäranden som visas före Analytics kodavsnitt, desto större är risken att du får problem med korta klick och saknad sessionsdata.
Ett annat sätt att se på korta klick är att de är faktiska användare som lämnar webbplatsen, vilket betyder att avvisningsfrekvensen kan bli artificiellt låg om du inte spårar de här avvisningssessionerna.
Mobila och korta klick: I allmänhet är nätverksinfrastrukturer för mobila enheter (3G-nätverk) långsammare än de flesta fasta anslutningar (ADSL/kabel). Om du riktar in dig på mobila enheter är det ännu viktigare att ha en snabb webbplats för att undvika korta klick.
En kortsiktig lösning för korta klick
En kortsiktig lösning är att försöka placera Analytics kodavsnitt för spårning så högt upp som möjligt i HTML-källkoden. I bästa fall ovanför eventuella andra Javascript-filer.
I skärmdumpen ovan kan du se att det finns flera Javascript-filbegäranden som måste utföras (synkrona taggar) innan Analytics kodavsnitt för spårning kan köras. Vi diskuterar optimeringstekniker senare, men för tillfället kan en kortsiktig lösning vara att placera Analytics kodavsnitt för spårning ovanför de andra Javascript-filerna. Men oroa dig inte: sidrenderingen blir inte långsammare med Analytics eftersom det har en asynkron JavaScript-tagg. Det betyder att sidan renderas även om det finns en fördröjning från Analytics-servern.
Anledningen till att det är en tillfällig lösning är att det kan hjälpa dig att registrera sessioner som du annars skulle ha missat på grund av användare som lämnar sidan tidigt (eftersom Analytics-kodavsnittet inte körs tidigare). Ditt långsiktiga mål är förmodligen att behålla de användare som lämnar webbplatsen och korrigera det underliggande problemet, det vill säga en webbplats som svarar långsamt.
Hur vet jag om webbplatsen är långsam?
Som vi redan nämnt hjälper det till viss del att placera Analytics kodavsnitt för spårning högre upp i HTML-koden, men det är också viktigt att ha en webbplats som svarar snabbare.
Så hur kan du veta om webbplatsen är långsam?
Test 1
Låt cacheminnet vara tomt (rensa cacheminnet och dina cookies om du vill) och öppna en ny flik. Ange måladressen i webbläsarens adressfält och öppna sedan utvecklarverktygen i Chrome på nätverksfliken.
Läs in webbplatsen och titta på listan med begäranden. Den ska se ut ungefär så här:
Leta reda på _utm.gif (klassisk Analytics) eller collect (Universal Analytics) och titta i avsnittet Tidsplan på höger sida. På bilden ovan kan du se att det gick ungefär åtta sekunder mellan den första begäran (då ett klick skulle registreras) och Analytics begäran (då en session skulle registreras).
Om en användare klickar på bakåt-knappen inom de här åtta sekunderna kan det hända att Analytics inte lyckas registrera en session på den här webbplatsen, men Google Ads registrerar klicket.
Kommer du ihåg citatet från KissMetrics-studien? ”Hälften av alla användare förväntar sig att en sida ska läsas in på två sekunder eller mindre.” Den här webbplatsen kan förbättras!
Test 2
Analytics registrerar data om sidhämtningstiden automatiskt i rapporterna om webbplatshastighet.
Den här rapporten hjälper dig att fokusera på specifika Google Ads-måladresser så att du kan se hur stor fördröjning de har. I just det här exemplet kan vi se att webbplatshastigheten är ungefär 25 sekunder för den här specifika webbadressen, vilket är väldigt långsamt.
Tänkte du på att avvisningsfrekvensen för den här sidan också är hög? Så även om den här måladressen redan leder till korta klick (dvs. avvisningar) har även de som registreras en högre avvisningsfrekvens, vilket inte är bra.
Optimalt bör en sidläsning ske på 3–4 sekunder.
Även om rapporterna för webbplatshastighet är en bra indikator för sidhämtningstiden baseras urvalet som standard på enbart 1 % av trafiken. Om du har ett relativt litet antal dagliga användare på webbplatsen, som 100 000 eller färre, kan det vara idé att välja ett större urval, t.ex. 5 %. Det ger mer detaljerad information om sidhämtningstider och andra mätvärden för webbplatshastighet.
Tänk på att det här skapar ytterligare en begäran, men det påverkar, i de allra flesta fall, inte användarupplevelsen på ett negativt sätt.
Hur kan jag göra webbplatsen snabbare?
I Analytics rapporter för webbplatshastighet ingår nu förslag på högre webbplatshastighet. Ange de måladresser som får flest antal klick för att se förslag på hur du kan göra de sidorna snabbare.
Ta bort omdirigeringar eller uppdatera måladresserna
Även om dina omdirigeringar bevarar Google Ads parameter för automatisk taggning och överför den till den slutliga måladressen, innebär omdirigeringar en extra fördröjning mellan klicket och tiden innan sessionen kan registreras av Analytics.
I de flesta fall har webbplatsägare flera omdirigeringar mellan Google Ads-klicket och den slutliga måladressen.
Du bör uppdatera din Google Ads-måladress så att den återspeglar den slutliga måladressen, så att inga omdirigeringar behöver utföras.
I vissa fall använder klienter en mellanliggande tjänst, som en klickserver, för att registrera Google Ads-klick, och de används ofta vid rapportering på plattformar från tredje part.
Vi förstår att du vill rapportera på flera plattformar, men den här tjänsten kan bli en flaskhals som gör användarupplevelsen långsammare. Om du har problem med klick och sessioner som registreras i Analytics rekommenderar vi att du försöker ta bort klickspårningstjänsten en tid för att se om förhållandet mellan antalet klick och sessioner förbättras. Sedan kan du ta ställning till om du vill fortsätta att spåra genom plattformen från tredje part, eller alternativt titta efter en leverantör som är snabbare.
CSS-sprites
CSS-sprites kan byta ut flera bildbegäranden.
Lägg märke till hur webbplatsen på bilden ovan har flera bildbegäranden (.png-filer) för småbildsikoner och -filer. Fördelen med CSS-sprites är enkel: i stället för att ha flera bildbegäranden placerar du alla bilder i en enda begäran (en större bild) och använder CSS för att styra vilka delar av den bilden som visas i olika områden på webbplatsen. En stor bildbegäran är snabbare än flera små bildbegäranden.
Använd ett nätverk för innehållsleverans (NFI)
Ett nätverk för innehållsleverans är ett utmärkt sätt att göra webbplatsen snabbare samtidigt som den blir mer skalbar och tillförlitlig. Det fungerar så att filer och innehåll som ofta hämtas från webbplatsen sprids ut över flera servrar på olika platser i världen.
Vanligtvis finns en webbhotellstjänst på en fast fysisk plats, till exempel i Kalifornien. Det fungerar bra för användare i Kalifornien eftersom innehållet på din webbplats visas snabbt för dem, men hur är det för användare i Australien eller Europa? De upplever en större fördröjning när de väntar på filer från Kalifornien, men genom att använda ett NFI kan de användarna ta emot filer från en server som finns närmare dem.
Genom att sprida webbplatsen över flera servrar världen över påverkas du också i mindre grad av driftstopp och andra infrastrukturproblem.
Ett NFI är mycket bra för innehåll som i allmänhet förblir statiskt eller inte ändras ofta, som till exempel Javascript-filer, CSS, HTML och annat bild- eller videoinnehåll. Det komprimerar också de här filerna så mycket det går genom att ta bort radbrytningar i Javascript-, CSS- och HTML-filer.
Google tillhandahåller ett eget NFI som kallas Google PageSpeed.
Komprimera HTML-, CSS- och JS-filer
Om du inte vill använda en NFI-tjänst (nämns ovan) kan du ändå hitta olika moduler, pluginprogram och kostnadsfria webbtjänster som automatiskt komprimerar innehåll genom att ta bort radbrytningar och samla flera filer (t.ex. CSS-filer) i en enda begäran.
Cachelagra populära begäranden
En populär webbserverstack använder Linux Apache MySQL PHP (LAMP).
I diagrammet ovan kan vi se att flera steg faktiskt utförs när en HTML-renderad sida returneras till användaren:
- Webbservern tar emot begäran.
- Webbservern skickar sedan begäran via PHP, som avgör vilka filer eller databasrader som ska användas.
- PHP packar upp och skapar den relevanta HTML-sidan som sedan returneras till användaren.
Hur cachelagring kan bidra
I många fall ändras inte sidinnehållet varje gång en användare begär sidan, till exempel en sida med Vanliga frågor. I stället för att gå igenom hela processen i diagrammet ovan kan vi skapa sidan en gång och cachelagra den som en temporär HTML-fil. Det betyder att webbservern inte behöver generera en sida via PHP upprepade gånger och anropa en databas om och om igen, utan i stället visas en statisk HTML-fil för de flesta användarna. Det här kan göra att webbservern inte behöver utföra ständig multitasking och webbplatsen blir snabbare för alla.
Det finns flera kostnadsfria moduler som utför den här uppgiften för din webbplats.
PHP användes i exemplet ovan, men det finns många andra webbservrar som bygger på samma princip och som sannolikt har liknande moduler för den här typen av cachelagring av sidor.
Överväg att använda ajax och pluginprogram som Infinite Scroll eller Lazy Load för Jquery
Har du tänkt på att vissa webbplatser läser in innehåll medan du bläddrar ned på sidan? YouTube gör det för miniatyrbilder av relaterade videoklipp, och kommentarsavsnittet är begränsat till de första resultaten om du inte begär att fler kommentarer visas.
Om du använder sådana tekniker rätt kan den första sidbegäran bli mycket mindre och användare kan börja interagera med sidorna direkt. Om de vill visa mer innehåll kan de bläddra längre ned för att aktivera fler objekt.
Det finns flera problem med användbarhet och tillgänglighet att tänka på när du inför den här typen av lösning. Du hittar mer information om det i dokumentationen till LazyLoad och InfiniteScroll.
Gzip-komprimering
Äldre webbläsare hade inte stöd för den här typen av sidkomprimering (HTML, CSS, Javascript osv.), men nyare webbläsare, inklusive mobila enheter, har det. Det bästa med den här funktionen är att det ofta är väldigt enkelt att använda den.
Du kan lära dig mer om Gzip i den här videon.
Uppgradera till Universal Analytics
Om du inte redan har uppgraderat till Universal Analytics (analytics.js) från den klassiska versionen (ga.js) kanske du vill prova att övergå till den senaste Analytics-plattformen. Du får åtkomst till de senaste produktfunktionerna, men Universal Analytics har också några förbättringar som är värda att notera:
- Modulbaserat bibliotek över spårningskod: analytics.js har externa moduler, som Ecommerce, som inte längre ingår för alla webbplatser (det är så ga.js fungerar). Det här minskar inverkan från analytics.js när det gäller filstorlek, vilket är detsamma som snabbare filöverföring.
- Minskat beroende av cookies: Universal Analytics beräknar nu kampanj- och sessionsdata på serversidan (istället för på klientsidan), vilket innebär att färre cookies överförs för varje filbegäran. Det kan ge en liten, men märkbar, förbättring.
Snabbare webbhotellsserver
Du kan gå miste om affärsmöjligheter om du har en långsam webbplats. Det kan vara värt att uppgradera till en snabbare webbhotellsserver.
Fler tips och förslag
Den här artikeln kan inte ta upp alla optimeringstekniker som finns, men vi visar dig gärna var du kan hitta många fler. Läs den här dokumentationen om du vill ha fler tips och förslag.
Till sist: tänk på att du kan förbättra webbplatsens hastighet och responstid, men att det ibland kan vara så att användare har långsamma internetuppkopplingar och långsamma mobilnätverk. Det här är i första hand ett problem i glesbefolkade områden och utvecklingsländer med begränsad eller gammal telekominfrastruktur.
Det bästa du kan göra under sådana omständigheter är att du gör webbplatsen så responsiv som möjligt, men även den mest optimerade webbplatsen kan stöta på problem med korta klick på grund av långsamma uppkopplingar.
