Core Web Vitals-redning for AI-bygde WordPress-nettsteder

#Core Web Vitals-redning for AI-bygde WordPress-nettsteder: problemet etter byggingen

En AI-assistent kan sette et WordPress-nettsted i drift på en eftermiddag. Den kan ikke fortelle deg at det fjerde “speed”-pluginet den anbefalte, kjemper mot det andre cache-laget den anbefalte to prompter tidligere. Eiere finner det vanligvis ut fra et PageSpeed Insights-skjermbilde med røde tall, eller fra en interessent som spør hvorfor et raskt utseende nettsted laster som i 2015. Dette er en redning skreddersydd for nettopp dette feilmønsteret: Core Web Vitals ødelagt spesifikt fordi byggingen ble satt sammen av prompter, ikke fordi bedriften bevisst valgte et tungt tema.

Dette er en snevrere tjeneste enn generell hastighetsoptimalisering. En standard ytelsesrevisjon forutsetter bevisste, om enn ufullkomne, arkitektoniske valg tatt over tid. Denne redningen forutsetter det motsatte: en assistent som besvarte ti separate forespørsler med ti separate plugininstallasjoner i én byggesesjon, og en page builder som leverer markup, CSS og JavaScript for hver blokk uavhengig av hva som faktisk vises over synlig område.

#Hvorfor AI-bygging ødelegger Core Web Vitals

Tre mekanismer viser seg i nesten hvert AI-assisterte prosjekt vi åpner, vanligvis sammen.

Pluginoverbelastning. Store språkmodeller har ikke en live-oversikt over hva som allerede er installert. Prompt én får et formplugin. Prompt femten får et andre formplugin, fordi modellen ikke husker prompt én. Hver installasjon er individuelt forsvarlig; den kumulative vekten er det ikke. De anonymiserte tallene bak dette mønsteret dokumenterte vi i pluginoverbelastning etter en AI-bygging: 38 aktive plugins er et rutinemessig startpunkt for et treukers AI-assistert prosjekt, ikke et unntak.

Dupliserte optimaliseringsverktøy. Den instinktive løsningen på en treg side er “installer et cache-plugin”. Når TTFB fortsatt er høyt en uke senere, er neste prompt “installer et raskere cache-plugin”, ofte uten å deaktivere det første. Vi finner regelmessig to fullsidecacher, to minifiere og to bildeoptimaliseringsplugins som kjemper mot hverandre på samme nettsted, noen ganger med periodisk ødelagt JavaScript fordi to minifiere omskriver de samme ressursene forskjellig.

Render-blokkerende builder-output. Page buildere genererer generisk, gjenbrukbar markup slik at hver blokk fungerer i hvert oppsett. Denne generiskheten betyr at hver blokk leverer sin egen CSS og JS, lastet uavhengig av posisjon i synlig område. En hero-seksjon bygget med en dra-og-slipp-builder pluss en tilleggspakke leverer rutinemessig mer render-blokkerende CSS enn hele siden faktisk trenger, som er nøyaktig det som trekker LCP og INP i rødt på mobil.

Vi så dette hos en nettbutikk som brukte Vipps-betaling: page builderens sjekkut-blokk lastet en egen tilleggspakke bare for betalingsknappen, og Vipps-widgeten kjørte sin egen skriptpakke i tillegg til to konkurrerende cache-plugins. INP på betalingssiden lå over 700ms før vi fjernet den overflødige tilleggspakken og lot builderen levere kun Vipps-widgeten direkte; etterpå falt INP til 180ms uten å endre hosting hos Domeneshop.

#Bevis fra praksis: 38 plugins til 21, TTFB 1,47s til 0,68s

Det klareste beviset er den anonymiserte saken dokumentert i sin helhet i pluginoverbelastning etter en AI-bygging. Et B2B-tjenestenettsted innen faglige tjenester, bygget over rundt tre uker med AI-assisterte verktøy, ankom med:

Hosting og tema endret seg ikke. Gevinsten kom fra å fjerne dupliserte SEO-, cache- og analyticsplugins, slå sammen tre formbuildere til én, og revidere tre tilpassede mu-plugins assistenten hadde generert, hvorav to ble slettet etter en sikkerhetsgjennomgang. Slik ser en Core Web Vitals-redning på et AI-bygd nettsted ut: mest avinstalleringer og sammenslåinger, ikke ny infrastruktur.

#Triage-tabell: symptom, årsak, tiltak

Kjør denne før du forplikter deg til et fullt oppdrag. Den viser om en rask gjennomgang er nok, eller om prosjektet trenger en trinnvis nedbygging.

Hvis de fleste radene peker på isolert pluginduplisering, er en fokusert nedbygging vanligvis nok. Hvis tilpasset AI-kode, pluginoverbelastning og ødelagte brukerflyter dukker opp sammen, planlegg for den fullere redningen i stedet for å lappe ytelse isolert.

#Trinnvis nedbyggingsrekkefølge

Ytelsesarbeid følger en fast rekkefølge slik at en fiks ikke reverseres av neste batch, og slik at sikkerhetsproblemer i tilpasset kode ikke avdekkes ved å fjerne pluginene som stille jobbet rundt dem.

1. Frys nye installasjoner. Ingen plugin-svar før revisjonsloggen finnes.
2. Fjern dupliserte cache- og optimaliseringsplugins først. To fullsidecacher som kjemper mot hverandre er den vanligste årsaken til inkonsistente PageSpeed-resultater; fiks dette før noe annet.
3. Revider tilpasset AI-kode før kommersielle plugins rundt den slettes. Hvis et generert mu-plugin stille er avhengig av et plugin du er i ferd med å fjerne, ødelegger sletting av pluginet først nettstedet.
4. Slå sammen overlappende verktøy i batcher på fem til åtte, test checkout og formler etter hver batch, mål TTFB og spørringsantall.
5. Fiks render-sti-problemer på malene som bærer trafikk: forsink ikke-kritisk JS, legg til uttrykkelige bilde- og fontdimensjoner, reduser tilleggsbruk i builderen på hero.
6. Mål på nytt og sett et pluginbudsjett slik at den neste AI-assisterte endringen ikke gjenåpner de samme hullene.

#Målesjekkliste: LCP, INP, CLS og TTFB

Følg alle fire sammen. En PageSpeed-score alene skjuler hvilken konkret metrikk som faktisk driver forretningseffekten.

• LCP (Largest Contentful Paint) - mål under 2,5s. Mål på selve hero-malen, ikke en lett testside.
• INP (Interaction to Next Paint) - mål under 200ms. Test på en side med form eller filter, der brukere faktisk interagerer.
• CLS (Cumulative Layout Shift) - mål under 0,1. Test med cookie-banner og lazy-lastede bilder til stede, siden disse er vanlige CLS-kilder på AI-bygde nettsteder.
• TTFB (Time to First Byte) - mål under ~800ms ukachet på en standardside. Mål med curl eller WebPageTest over fem kjøringer og bruk medianen, ikke en enkelt prøve.
• Databasekall per visning - følg med Query Monitor; flagg alt over rundt 120 på en innholdsside.

Mål på forsiden, den tyngste landingssiden og checkout eller kontakt. Et nettsted som ser raskt ut på forsiden og trått ut i checkout er et vanlig AI-byggemønster, fordi builder-tunge sider sjelden er de som ble testet sist.

#Hva du ikke bør gjøre

• Installer ikke enda et optimaliseringsplugin for å fikse et trått nettsted forårsaket av for mange plugins. Det er hvordan nettsteder når 40 plugins i utgangspunktet.
• Kjør ikke to fullsidecacher “for sikkerhets skyld”. Velg én og konfigurer den riktig.
• Slett ikke tilpassede AI-genererte mu-plugins før du har revidert hva de er avhengige av. Noen patcher stille et hull et annet plugin lot stå åpent.
• Jag ikke en syntetisk 100-score i PageSpeed på bekostning av ekte LCP/INP/CLS på malene som genererer inntekt.
• Hopp ikke over å måle checkout- og kontaktsider fordi “forsiden er jo fin”. Sekundære, builder-tunge maler er vanligvis der de verste tallene bor.

#Slik forløper oppdraget

Trinn 1 - basis. Vi måler LCP, INP, CLS og ukachet TTFB på representative maler, pluss en full plugin- og databaseinventar.

Trinn 2 - revisjon. Hvert plugin kartlegges mot sin faktiske jobb; duplikater og render-blokkerende builder-output flagges.

Trinn 3 - trinnvis nedbygging. Batcher på fem til åtte plugins, deaktivert, testet, målt, deretter slettet. Ingen masseutsletting i produksjon.

Trinn 4 - render-sti-fikser. Forsinkelse av ikke-kritiske skript, fiks av bilde- og fontlasting, konsolidering til ett cache-lag.

Trinn 5 - ny måling og budsjettfastsetting. Samme maler, samme verktøy, dokumentert før/etter, pluss en regel om at ingen ny plugin skipes uten å pensjonere eller slå sammen en eksisterende.

#Relaterte tjenester og fordypninger

Denne redningen står side om side med det bredere saneringsarbeidet vi gjør på genererte nettsteder:

Bloggfordypning: Pluginoverbelastning: når en AI-bygging etterlater deg 40 plugins dypt - den fulle anonymiserte saken bak tallene brukt ovenfor.

Prisen er individuell og fastsettes etter basisrevisjonen. Kontakt oss med nettstedet og en kort notat om hvordan det ble bygget.