100/100 Core Web Vitals på WordPress

Alle sier de optimaliserer for hastighet. Få kan bevise det. Denne uken fullførte vi en ytelsesoverhaling for en kunde i den konkurranseutsatte e-handelsbransjen for “Hjemmeinnredning”.

Startpunktet:

• Mobilscore: 42/100
• LCP: 4,8 s
• INP: 450 ms (Dårlig)
• CLS: 0,25 (Layoutforskyvning overalt)

Resultatet (Etter 4 uker):

• Mobilscore: 100/100
• LCP: 1,2 s
• INP: 48 ms
• CLS: 0,00

Dette var ikke magi. Det var ingeniørkunst. Her er nøyaktig hvordan vi gjorde det.

#1. Fikse LCP (Largest Contentful Paint)

Skurken: Hero Slideren. Kunden brukte en tung Revolution Slider. Den lastet 4 MB JavaScript før det første bildet ble vist.

Løsningen:

1. Slett Slideren: Vi erstattet slideren med en statisk CSS Grid-layout.
2. Fetch Priority: Vi la til <img fetchpriority="high"> på hoved-hero-bildet. Dette forteller nettleseren “Last ned dette FØR logoen og menyen.”
3. AVIF-format: Vi konverterte alle PNG-er til AVIF. Overskriftsbildet på 800 KB ble 45 KB.

Resultat: LCP falt fra 4,8 s til 1,9 s umiddelbart.

#2. Løse CLS (cumulative layout shift)

Skurken: Egendefinerte skrifttyper og Lazy Loading.

1. Skrifttyper: Teksten dukket opp, deretter lastet den egendefinerte skrifttypen, og forskjøv oppsettet med 10 piksler.
2. Bilder: Lazy-loaded bilder dukket opp og skjøv tekst ned fordi de manglet width og height attributter.

Løsningen:

1. Font Preloading: Vi la til <link rel="preload"> for den primære skrifttypen og brukte font-display: optional. Hvis skrifttypen ikke laster innen 100 ms, holder nettleseren seg til systemskrifttypen for alltid (ingen forskyvning).
2. Aspect Ratio: Vi tvang aspect-ratio: 16/9; på alle bildebeholdere i CSS. Nettleseren reserverer det hvite rommet selv før bildet lastes ned.

Resultat: CLS falt til 0,00.

#3. Knuse INP (interaction to next paint)

Skurken: Tredjepartsskript. Chat-widgets, Facebook Pixel, Google Tag Manager, Hotjar. De kjempet alle om hovedtråden. Når en bruker klikket på “Meny”, var nettleseren for opptatt med å spore brukeren til å åpne menyen.

Løsningen: Partytown. Vi flyttet alle distinkte tredjepartsskript til en Web Worker ved hjelp av Partytown. Dette kjører den tunge sporingskoden på en bakgrunnstråd. Hovedtråden (UI) forblir silkemyk.

Resultat: INP falt fra 450 ms til 48 ms.

#4. Det hemmelige våpenet i 2026: Speculation rules API

Vi ville ikke bare at det skulle være raskt. Vi ville at det skulle føles umiddelbart. Vi implementerte Speculation Rules API.

Når en bruker holder musepekeren over et produktkort, gjør nettleseren følgende:

1. Forhåndsheter (Prefetch) HTML-en til neste side.
2. Forhåndsgjengir (Prerender) den i en skjult bakgrunnsfane.

Når de klikker, er sideinnlastingen bokstavelig talt 0 ms. Den er allerede der.

#5. Optimalisering på serversiden (infrastrukturen)

Du kan ikke få en score på 100 på en server til 50 kroner. Vi migrerte kunden til en WordPress VIP-lignende arkitektur (eller konsistent high-end).

1. Redis Object Cache: Databaseforespørsler for “Meny” og “Alternativer” bufres i RAM.
2. Edge Caching (Cloudflare Enterprise): Hjemmesidens HTML serveres fra en server i Oslo, ikke opprinnelsen i New York. TTFB falt fra 600 ms til 40 ms.

#6. Forretningsmessig innvirkning

Hvorfor gjorde vi alt dette? Ikke for forfengelighetsmålinger.

• Fluktfrekvens (Bounce Rate): Sank med 18%.
• Annonsebruk: CPC falt med 12% (Google Ads kvalitetspoeng forbedret på grunn av hastighet).
• Inntekter: Organisk trafikk vokste 40% på 2 måneder ettersom Google belønnet “Page Experience”-signalene.

Konklusjon: Hastighet er ikke teknisk gjeld. Det er en inntektsspak.

Lekker din WooCommerce-butikk penger på grunn av treghet? WPPoland optimaliserer for grønne poengsummer og grønne bankkontoer.