En mobilbesökare bör kunna läsa en kategorisida innan webbläsaren har laddat klart allt som finns bakom den. Det var min utgångspunkt för en veckas arbete med prestanda för vape-webbplats på Cigge, från den 25 september till den 2 oktober 2026.
Cigge är en svensk nätåterförsäljare med en vape- och e-cigarettkatalog hos Cigge, e-vätskor och tillbehör. Cigges företagssida beskriver verksamheten och nätbutiken. Jag arbetar med den tekniska webbplatsen; detta är en redogörelse för det arbetet, inte en oberoende produktrekommendation.
Arbetet omfattade CSS för den första vyn, JavaScript-laddning, duplicerade katalogdata och cachebeteende. En kontrollerad förhandsjämförelse registrerade en lägre simulerad Largest Contentful Paint på mobil: ett medianvärde på 5,62 sekunder i kontrollen jämfört med 5,176 sekunder efter ändringarna, inom en specifik grupp testkörningar.
Det resultatet behöver sättas i sammanhang. Det är en lab jämförelse i förhandsmiljöer, inte ett påstående om att alla besökare nu ser hela webbplatsen laddas 7,9 % snabbare.
En svensk vape-webbplats måste fortfarande fungera som en riktig butik
En e-handelskategorisida har fler uppgifter än en landningssida. Den måste visa produktinformation, hålla priser och tillgänglighet korrekta, stödja filter och sortering samt låta besökare navigera tillbaka utan att förlora sin plats.
För en webbplats som betjänar kunder i Sverige är mobil layout och lättläst svenskt innehåll lika viktigt som laddningstid. En kategoriöverskrift som visas snabbt är användbar. En snabb överskrift följd av ett trasigt filter eller ett produktgaller som hoppar räcker inte.
Cigge använder en Next.js-butik med PrestaShop bakom katalogen. Den uppdelningen ger mig kontroll över vad webbläsaren tar emot. Den gör det också enkelt att skicka mer data och JavaScript än en viss sida behöver.
Jag tog mig an veckan som en serie små ändringar med regressionskontroller. Jag ville ta bort onödigt arbete samtidigt som butikens befintliga beteende bevarades.
Den första diagnosen: titta bortom poängen
Granskningen av den offentliga startsidans payload den 28 september registrerade 987 836 byte HTML. I det dokumentet stod den inbäddade React Flight-strömmen för 492 120 byte. Flight är de serialiserade data som React använder för att överföra information om serverrenderade komponenter till webbläsaren.
Samma granskning identifierade 270 853 byte initialt tillstånd från sidbyggaren, 96 628 byte översättningsmeddelanden och 47 640 byte bootstrap-data.
Källa: vår registrerade payload-granskning av den offentliga sidan. Detta är serialiserade byteantal, inte komprimerade storlekar för nätverksöverföring. Kategorierna överlappar: Flight-strömmen ligger inuti dokumentet och utökade komponentdata kan överlappa inom Flight. Lägg inte ihop staplarna. Detta är en diagnostisk ögonblicksbild, inte ett före- och efterresultat.
De siffrorna hjälpte mig att ställa mer användbara frågor. Behöver den här routen hela varumärkeslistan direkt? Behöver ett produktkort fält från produktdetaljsidan? Kopierar vi identiska prisrader till flera varianter?
Jag föredrar att besvara de frågorna framför att ta bort data på måfå för att få en rapport att se grönare ut.
Ge den första vyn dess stilar först
Jag separerade CSS som behövs för den första synliga skärmen från de större stilprofilerna för butiken. Servern inkluderar den kritiska delmängden i HTML, så att webbläsaren kan formge den skärmen utan att vänta på hela profilens stylesheet.
De senare ändringarna på kategorisidor skjuter upp den större profilen tills efter first contentful paint. Det innebär att webbläsaren kan visa innehållet innan den begär styling som den första skärmen inte behöver.
Detta kräver omsorg. Klientbaserad navigering behöver fortfarande rätt stilar. Bakgrundsflikar kan inte vänta för evigt på en paint-händelse. Besökare med JavaScript inaktiverat behöver en fallback. Jag behöll dessa fall i implementationen och kontrollerna i stället för att behandla den första skärmbilden som hela uppgiften.
Det finns en avvägning: på långsammare anslutningar kan styling längre ned på sidan komma senare. Kritisk CSS måste täcka den faktiska första vyn, och tidig scrollning bör testas. Att skjuta upp ett stylesheet utan att kontrollera den gränsen skulle kunna byta ut en laddningsfördröjning mot en synligt ofärdig sida.
Flytta valfritt arbete utanför fönstret för första visningen
På kategorisidan vi undersökte var Largest Contentful Paint-elementet beskrivningstext, inte en produktbild. Att komprimera ytterligare en bild skulle inte åtgärda just den flaskhalsen.
Jag flyttade registreringen av nyligen besökta kategorier till ett separat, uppskjutet klientpaket. Den registrerar fortfarande besöket för snabbåtkomstmenyn, men behöver inte konkurrera med det första synliga innehållet.
Logotyperna i sidhuvud och sidfot flyttades också till bildsökvägar från samma origin via den befintliga bildproxyn. Bildinnehållet förblev detsamma; begäran behövde inte längre en separat anslutning mellan butikens origin och CDN för dessa resurser.
Jag behöll också klientkod som bara används på startsidan på startsidan i stället för att ladda den via kategori- och produktrouter. Sökning och kataloginteraktioner finns fortfarande där besökarna behöver dem. Målet var att låta varje route bära sina egna ansvarsområden.
Det uppmätta resultatet för kategorisidan
Så kördes jämförelsen
Den registrerade jämförelsen använde PageSpeed Insights mobiltester mot två förhandsmiljöer på samma kodbas och stagingdata: en kontrollversion och en ändrad version. Den körde åtta alternerande omgångar per butik, med minst 75 sekunder mellan begäranden till samma URL.
Testprotokollet separerade körningar efter när den observerade första paint-händelsen inträffade i förhållande till att dokumentet blev färdigt. Diagrammet nedan visar endast gruppen med sen paint, med fyra till fem körningar per sida. Det sammanfattar inte alla åtta omgångar.
Källa: vår registrerade förhandsjämförelse. Lägre är bättre. Skillnaden mellan dessa medianvärden är 444 millisekunder, eller cirka 7,9 %. Detta är simulerade labbtider för delmängden med sen paint, inte mätningar från besökare i produktion.
Vad siffrorna betyder
Kontrollens intervall var 5,476–5,721 sekunder; intervallet för den ändrade förhandsversionen var 5,176–5,326 sekunder. Intervallen överlappade inte i den registrerade delmängden. Körningar med tidigare paint betedde sig annorlunda, så jag skulle inte omvandla detta resultat till en procentandel för hela webbplatsen.
Jag tycker att den skillnaden är användbar när man diskuterar PageSpeed med en kund. Vi har bevis för att en specifik ändring minskade en specifik uppmätt fördröjning under de testade förhållandena. Vi behöver fortfarande fältdata för att förstå effekten på verkliga enheter och nätverk.
Mindre JavaScript i webbläsaren utan att ta bort HTML-kontroller
En annan ändring flyttade sanering av butikens HTML till servrarna som producerar innehållet. Tidigare inkluderade offentliga klientpaket DOMPurify för att sanera innehåll som servern också renderade.
Den registrerade byggjämförelsen visade cirka 15,4 KB mindre initialt JavaScript, komprimerat med Brotli quality 3, på Cigges kategoriroute. Det är ett mått på paketstorlek, inte ytterligare en procentuell förbättring av laddningstiden.
Implementationen behåller saneringen på servern och skickar sanerade fält till renderingskomponenterna. Administratörsredaktörer kan fortfarande ladda saneraren när redigering kräver det. En byggkontroll säkerställer att biblioteket inte återkommer i vanliga klientpaket för butiken.
Jag skulle inte ta bort en HTML-förtroendegräns för att spara byte. Att flytta arbetet kräver att man spårar producenter, dynamiska svar och vägar via webbläsarlagring. Granskningsprotokollet innehåller dessa kontroller samt jämförelser av renderad markup och interaktiva flöden.
Skicka katalogdata en gång, där det är möjligt
Veckan omfattade också en mindre klientprojektion av katalogen. Vissa variantposter upprepade samma prisrader på produktnivå. Implementationen tar bort identiska kopior samtidigt som variantspecifika skillnader och fullständiga poster där produktdetaljer behöver dem behålls.
Varumärkesdata följer en liknande princip. Butiken behöver inte längre inkludera hela tillverkarlistan i den initiala bootstrapen på varje sida. Sök- och varumärkeskontroller begär den när det behövs, med gemensam laddning och hantering av nya försök.
Dessa ändringar kräver mer omdöme än att ta bort ett fält från ett svar. Priser, variantval, lagerstatus och navigering måste fortsätta fungera. En mindre payload hjälper bara om besökaren fortfarande får den information som gränssnittet lovar.
Cachearbetet följde samma logik: ogiltigförklara innehållet som ändrades, undvik att bygga om orelaterade sidor och värm utvalda katalogrouter efter driftsättning. Lagerkänslig information behöver fortfarande egna regler för korrekthet. En varm cache är användbar; inaktuell tillgänglighet är ett fel.
Prestanda för vape-webbplats och SEO
I detta fall av prestanda för vape-webbplats håller jag laboratoriemätningar åtskilda från besökarupplevelsen. Googles guide till mätning av Web Vitals förklarar skillnaden mellan kontrollerade labbdata och data från verkliga användare. PageSpeed Insights fältrapportering omfattar de föregående 28 dagarna, så en veckas ändringar ersätter inte omedelbart hela rapporteringsperioden.
LCP beskriver laddningen av det största synliga innehållet, INP beskriver responsiviteten vid interaktion och CLS beskriver oväntade layoutförflyttningar. Googles översikt över Web Vitals förklarar mätvärdena och deras trösklar. Ett laddningstest kan inte ensamt fastställa kvaliteten på varje interaktion.
En svensk vape-katalog behöver också användbar kategor information och tillförlitlig mobil navigering. Jag vill att besökare ska hitta lättläst innehåll och fungerande kontroller, snarare än en sida som bygger på att upprepa ett sökord.
Google säger att Core Web Vitals bidrar till dess rankningssystem, men bra poäng garanterar inte topplaceringar. Dess vägledning om sidupplevelse varnar också för att jaga en perfekt poäng enbart för SEO. Jag påstår inte att veckans arbete har lett till en ökning av ranking eller konvertering.
Vad jag skulle kontrollera härnäst
Det granskade arbetet med första paint på kategorisidan och ändringarna för sanering enbart på servern slogs samman under denna period. De registrerade kontrollerna omfattar produktionsbyggen, webbläsarnavigering och markupjämförelser. Jag rapporterar dessa tekniska poster här, inte som en nyligen upprepad produktionsgranskning.
Mina nästa kontrollpunkter är:
Jag har skrivit om att behålla en befintlig backend samtidigt som frontend byggs om i Headless WordPress AI Migration in One Day. Backend skiljer sig här, men ansvaret är liknande: bevara verksamhetens arbetsflöde samtidigt som den offentliga upplevelsen förbättras. Min uppföljning om headless-driftsättning behandlar de separata releasefrågorna.
För mig är det användbara resultatet av denna vecka en tydligare laddningssekvens, mindre redundant arbete i webbläsaren och en uppmätt förbättring av kategorisidan under dokumenterade förhållanden. Det är en starkare grund för nästa ändring än en skärmbild av en ovanligt bra poäng.
Om din e-handelssida behöver samma undersökning kan du kontakta mig om en prestandagranskning. Jag kan hjälpa till att skilja mellan problem med payload, rendering och cache och sedan definiera kontroller som skyddar befintliga kundflöden.
Visuell notering: hero-bilden är en AI-genererad redaktionell illustration, inte en skärmbild av Cigge eller en prestandarapport. De två diagrammen använder de registrerade mätningar som beskrivs ovan.