Webbplatser snabbas ofta upp i fel ordning: någon installerar ett optimeringsplugin, aktiverar varje reglage och försöker sedan förstå varför formuläret inte längre fungerar. Rätt ordning är mätning, en hypotes, en förändring, en funktionskontroll och en ny mätning.
I en äldre version beskrev jag också metoder som jag inte längre rekommenderar, till exempel att köra andras skript lokalt via en proxy eller att införa AMP och PWA generellt. De gav delvisa förbättringar i labbtester, men medförde risker med föråldrad kod, trasiga uppdateringar och mer komplicerat underhåll. En modern webbplats bör vara snabb i sin huvudversion.
Vad du bör mäta i dag
För Core Web Vitals använder Google tre stabila mätvärden:
- LCP: laddning av huvudinnehållet; ett bra värde är högst 2.5 sekunder.
- INP: svar på interaktioner; ett bra värde är under 200 millisekunder.
- CLS: oväntade layoutförskjutningar; ett bra värde är högst 0.1.
Tröskelvärdena gäller 75:e percentilen och sammanfattas i den officiella översikten Core Web Vitals för Google Sök. Resultat från verkliga besökare i Search Console eller CrUX väger tyngre än ett enda labbtest på min bärbara dator.
Labbverktyg är fortfarande viktiga: de visar vattenfallet, huvudtråden, oanvänd kod och konkreta åtgärdskandidater. Fältdata visar att ett problem finns; labbet hjälper till att förklara varför.
Definiera först problemets omfattning
- Jämför mobil och dator.
- Separera mallar: startsida, artikel, tjänst, listning, formulär och webbutik.
- Kontrollera snabba och långsamma länder, enheter och trafikkällor.
- Hitta URL-grupper med dåliga fältdata.
- Samla in ett upprepningsbart labbspår för en representativ sida.
En snabb startsida betyder inte att webbplatsen är snabb. Ett långsamt besök på en gammal telefon betyder inte att hela systemet måste skrivas om.
Åtgärder med vanligast effekt
1. Server och HTML
Mät tiden till första byte och dela upp den i DNS, anslutning, väntan på servern och omdirigeringar. Långa väntetider kan bero på webbhotellet, databasen, en sida utan cache, ett långsamt API eller omdirigeringskedjor. Aktivera lämplig sidcache för offentligt innehåll och objektcache där det är meningsfullt. Undanta inloggade användare, kundvagnar och personalisering från cachen på rätt sätt.
2. Huvudbilden
LCP är ofta hero-bilden. Leverera en storlek som motsvarar visningen, använd srcset, komprimering och moderna WebP eller AVIF med en rimlig reservlösning. Lazy-loada inte huvudbilden; lazy-loada bilder under den första viewporten. Ange bildens bredd och höjd så att webbläsaren reserverar utrymme och CLS förblir lågt.
3. CSS och typsnitt
Ta försiktigt bort oanvända stilar och håll kritisk CSS liten. Begränsa typsnitt till nödvändiga vikter och teckenuppsättningar, cacha lokala filer länge och förladda bara ett typsnitt som verkligen behövs tidigt. Att förladda tio typsnitt skapar bara ytterligare en kö.
4. JavaScript och interaktion
Dela upp stora paket, fördröj icke-kritisk kod och ladda bara tredjepartskod när den behövs och samtycke tillåter det. async och defer är ingen magi; testa skriptordning och beroenden. Dela upp långa uppgifter på huvudtråden och låt inte ett klick vänta på analysverktyg.
5. Tredjepartstjänster
Chattar, heatmaps, annonspixlar, videor och A/B-verktyg lägger till nätverksförfrågningar och processorarbete. Varje skript behöver en ägare och ett affärsmässigt skäl. Ladda det inte synkront i sidhuvudet bara för att installationsguiden blir kortare. Analys kan hanteras via Google Tag Manager, men containern kan inte i sig rädda prestandan.
WordPress: färre lager, mer kontroll
WordPress-dokumentationen rekommenderar att prestandan hanteras genom webbhotell, antal och kvalitet på plugin, bilder, cache och ett leveransnätverk. Läs deras optimeringsöversikt och den separata förklaringen av cache.
- Uppdatera WordPress, PHP, temat och plugin på staging först.
- Ta bort oanvända plugin och överlappande cache- eller minifieringsverktyg.
- Profilera databasfrågor och långsamma externa anrop.
- Planera databasunderhåll, men radera inte revisioner eller metadata blint.
- Testa formulär, sökning, inloggning och köpprocessen efter varje optimering.
Jag diskuterar ett förnuftigt val av tillägg i de bästa WordPress-tilläggen.
Vad du inte ska göra
- Ladda inte ner andras analys- eller annonsskript till din server bara för ett bättre resultat; du kan förlora säkerhets- och funktionsuppdateringar.
- Ställ inte in ett årslångt cachevärde för en fil som förändras utan att versionsmärka namnet.
- Ta inte bort CSS eller JavaScript från en automatiserad rapport utan att testa varje mall.
- Bedöm inte framgång enbart utifrån Lighthouse. Google säger uttryckligen att bra Core Web Vitals i sig inte garanterar höga placeringar eller en bra användarupplevelse.
- Snabba inte upp en webbplats genom att dölja innehåll eller en funktion som kunden behöver.
En plan på fyra veckor
- Vecka 1: baslinje för fältdata, labbmätningar och mallista.
- Vecka 2: server, cache, omdirigeringar och de största LCP-resurserna.
- Vecka 3: bilder, typsnitt, CSS, JavaScript och tredjepartstjänster.
- Vecka 4: regressionstest, nya mätningar, övervakning och dokumentation.
Dokumentera datum, URL, mätvärde före och efter, funktionell påverkan och möjlighet till återställning för varje förändring. Följ också konverteringsgrad, formulärslutförande och fel; en snabbare sida som säljer mindre är inte en färdig optimering.
Börja med att kontrollera webbplatsens tekniska grunder och analys i en teknisk granskning och GA4. Om du behöver prioritera åtgärder efter effekt och kostnad kan du kontakta mig via kontakt.