Prioritera Core Web Vitals för besökare med hög köpintention
Lär dig hur du använder RUM-data för att övervinna blinda fläckar i Core Web Vitals

Prioritera Core Web Vitals för besökare med hög köpintention
Många av mina kunder bryr sig djupt om att klara Core Web Vitals. Att klara Core Web Vitals innebär att 75% av all trafik bör klara Core Web Vitals. Ett beundransvärt mål! Men vid optimering för 75% av besökarna kan en liten men kritisk grupp på cirka 5% av besökarna förbises. Tyvärr är detta ibland den viktigaste gruppen: besökarna som kommer att konvertera till kunder!
Table of Contents!
Hitta blinda fläckar i CWV-analysen
Även om fokus på övergripande CWV-mätvärden är avgörande för en bra user experience, kan det dölja prestandaproblem som specifikt påverkar besökare med högt värde. Core Web Vitals-optimering, främst på grund av Google-bonusen, tenderar att fokusera på att optimera den 'något under genomsnittliga besökaren'.
Inom e-handel är det mycket meningsfullt att gå bortom detta perspektiv och lägga extra fokus på besökare med hög köpintention. Det är besökarna som konverterar till kunder. Att optimera Core Web Vitals för dessa besökarsegment kommer att leda till högre konverteringsgrader och lägre andel övergivna varukorgar.
Vi kan vanligtvis identifiera dessa användare genom antalet varor i deras varukorg.

Här uppstår problemet: att lägga till varor i en varukorg kan påverka core web vitals. Problemet är caching-plugins!
Caching-plugins inaktiverar ofta caching för användare med dynamiskt innehåll. Dynamiskt innehåll är innehåll som ändras per användare. Något så enkelt som 'varor i en varukorg', tvingar servern att bygga om hela sidan vid varje förfrågan. Detta ökar Time to First Byte avsevärt, vilket leder till långsammare First Contentful Paint och Largest Contentful Paint. Som resultat upplever användare med köpintention en långsammare webbplats jämfört med de som bara surfar.
Prioritera prestanda för dynamiskt innehåll
Gå bortom caching-plugins: Förlita dig inte enbart på caching-plugins. Försök att åtgärda så många av de underliggande problemen och flaskhalsarna som möjligt innan du vänder dig till plugins. Analysera din backend-kod, optimera databasfrågor, finjustera servern för att säkerställa en snabb TTFB, även utan caching-plugins.
Partiell caching: Överväg att cacha mindre delar av din webbplats som är CPU- eller tidskrävande att generera i realtid. Detta gör att du, när helsidescaching är inaktiverad, fortfarande snabbt kan generera hela sidan. Ditt CMS stöder vanligtvis partiell caching med Memcached eller Redis.
Client-Side Rendering (CSR) för dynamiska komponenter: Överväg att implementera CSR för inloggade användare. Med client side rendering serveras majoriteten av sidan fortfarande som cachad HTML (denna del är server-side renderad) medan mindre, dynamiska delar av sidan (som varukorgen eller personaliserade resultat) renderas client side. Efter att sidan har laddats använder webbläsaren JavaScript och AJAX för att hämta dynamiskt innehåll (som varukorgsinformation) och injicera det i den statiska sidan, vilket får den att framstå som dynamisk.
Effektiv cachehantering: Jag är ett stort fan av caching och jag uppmanar dig att implementera effektiva strategier för cachehantering som nyckelbaserad caching. Använd enkla nycklar för statiska element (till exempel kan en URL räcka som nyckel för en cachad sida) och använd komplexa nycklar för dynamiskt innehåll som varukorgar (nyckeln kan inkludera användar-ID, produkt-ID och tidsstämplar för att säkerställa att hämtad data matchar användarens specifika varukorg).
Stop debating in Jira.
Get a definitive answer on your performance issues. I deliver a granular breakdown of your critical rendering path.
- Definitive Answers
- Granular Breakdown
- Critical Path Analysis

