Ytelsesovervåking for enterprise WordPress: APM, varsler og Core Web Vitals

Ytelsesovervåking for enterprise WordPress svarer på tre spørsmål: hva ekte besøkende opplever, om neste release gjorde noe verre, og hvilket lag i stacken som har ansvaret. Hvert spørsmål trenger sitt eget instrument. Feltdata fra ekte brukere (RUM) svarer på det første, syntetiske tester i deploy-pipelinen på det andre, og verktøy på serversiden (Query Monitor, en APM-agent, OpenTelemetry-traces, MySQL slow query log, Redis-statistikk) på det tredje.

En treg checkout eller en stigende Interaction to Next Paint (INP) på nettstedet for ett marked koster omsetning og synlighet i søk lenge før noen melder en feil. Moderne WordPress-oppsett er fordelt på CDN, PHP-workere, database, objektcache og noen ganger en separat frontend, så “er serveren oppe?” sluttet å være et nyttig spørsmål for mange år siden. Denne guiden beskriver en overvåkingsstack for slike oppsett, og hver terskel og innstilling er hentet fra dokumentasjonen til leverandøren eller standarden som er lenket i teksten.

#RUM eller syntetisk overvåking av WordPress

For å få et fullstendig bilde må du overvåke fra to perspektiver. De konkurrerer ikke: hver av dem ser noe den andre ikke kan se.

#Real user monitoring (RUM)

RUM registrerer opplevelsen til hver enkelt besøkende, på deres enhet og i deres nett.

• Enhetsfragmentering: hvordan nettstedet yter på en ny iPhone sammenlignet med en Android-telefon i mellomklassen på en overbelastet mobilforbindelse.
• Interaktivitet: hver interaksjon som inngår i INP, slik at du finner de konkrete grensesnittelementene brukerne opplever som trege.
• Edge-ytelse: den faktiske ventetiden mellom en besøkende og nærmeste CDN-lokasjon, per land.

Et gjennomsnitt for hele nettstedet skjuler det meste som betyr noe. Del RUM-dataene etter enhetsklasse, tilkoblingstype, land, mal (innlegg, arkiv, produkt, handlekurv) og første besøk mot gjentatt besøk. Rapporter 75. persentil, fordi det er verdien Google bruker til å vurdere Core Web Vitals. Artikkelen om Web Vitals på web.dev formulerer måleregelen slik:

“75. persentil av sidevisningene, delt opp etter mobile enheter og datamaskiner”

Kilde: Web Vitals, web.dev (egen oversettelse)

#Syntetisk overvåking og oppetidstester

Syntetiske tester laster sidene dine med skriptstyrte nettlesere under kontrollerte forhold.

• CI/CD-integrasjon: en Lighthouse-kjøring hver gang en utvikler pusher en endring i tema- eller plugin-koden.
• Oppetids- og brukerreisetester: skriptstyrte gjennomganger av stiene som gir omsetning (“legg i handlekurv”, “send kontaktskjema”) fra regionene du selger i, med fast intervall.

Syntetiske tester ser ikke ekte brukere, så de erstatter aldri RUM. Styrken deres er at testforholdene er konstante. Når et syntetisk resultat blir dårligere, ligger årsaken i koden eller infrastrukturen, ikke i hvem som besøkte nettstedet den dagen.

#Slik samler du inn Core Web Vitals med web-vitals-biblioteket

Du trenger ikke et tungt tredjepartsskript for å komme i gang. Googles web-vitals-bibliotek beskriver seg selv som et lite, modulært bibliotek (rundt 3K med brotli) og måler hver metrikk på samme måte som Googles egne verktøy rapporterer den. Det leser nettleserens ytelses-API-er på siden og gir hvert resultat til en callback; deretter sender navigator.sendBeacon verdien til collectoren din, og README-filen til biblioteket påpeker at denne metoden fungerer selv mens siden lukkes.

import { onCLS, onINP, onLCP } from 'web-vitals';

function sendToTelemetry(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    delta: metric.delta,
    id: metric.id,
    page: window.location.pathname
  });

  if (navigator.sendBeacon) {
    navigator.sendBeacon('/api/telemetry/vitals', body);
  } else {
    fetch('/api/telemetry/vitals', { body, method: 'POST', keepalive: true });
  }
}

onCLS(sendToTelemetry);
onINP(sendToTelemetry);
onLCP(sendToTelemetry);

Eksemplet sender bare pathname, uten query string. Det valget betyr noe for personvernet, som beskrevet nedenfor.

Attribution-builden av det samme biblioteket gjør et dårlig tall om til en oppgave noen kan ta. For LCP oppgir den selektoren til LCP-elementet (target), bilde-URL-en der det finnes en, time to first byte, forsinkelse og varighet for lasting av ressursen og forsinkelsen i renderingen av elementet. For INP oppgir den elementet brukeren samhandlet med, input delay, behandlingstid og presentasjonsforsinkelse, i tillegg til longAnimationFrameEntries, Long Animation Frame-oppføringene som overlappet interaksjonen i nettlesere som støtter det API-et. “INP er dårlig på produktsider” blir til “variantvelgeren bruker mesteparten av tiden i ett bestemt skript”.

#Hvorfor Search Console og PageSpeed Insights ikke er nok

Search Console og PageSpeed Insights viser feltdata fra Chrome UX Report (CrUX). Dokumentasjonen for CrUX API beskriver disse dataene som et glidende 28-dagers gjennomsnitt av aggregerte metrikker, oppdatert daglig rundt 04:00 UTC. En regresjon som ble rullet ut i morges, flytter dette gjennomsnittet sakte, så du får vite om den dager eller uker etter at den startet.

Dekningen er den andre begrensningen. Ifølge CrUX-metodikken må en side eller et origin være offentlig synlig og tilstrekkelig populær for å komme med i datasettet, og bare Chrome-brukere som har samtykket bidrar, på datamaskin og Android. Chrome på iOS, apper med Android WebView og andre Chromium-nettlesere som Edge bidrar ikke med data. En B2B-portal bak innlogging, et nettsted for et marked med lite trafikk eller et publikum som stort sett bruker iPhone kan ha lite eller ingen CrUX-data.

CrUX er fortsatt riktig referanse for SEO, fordi det er datasettet Google rapporterer Core Web Vitals fra. For å reagere samme dag som en utrulling trenger du din egen RUM-datastrøm uten gjennomsnittsvindu.

#Slik gjør du RUM-overvåking i tråd med GDPR

Hvert RUM-beacon er en forespørsel fra den besøkendes nettleser til collectoren din. Hvis det inneholder en IP-adresse, en sesjons-ID eller en full URL med parametere (tenk på en e-postadresse i en lenke fra et nyhetsbrev), behandler du personopplysninger etter personvernforordningen (GDPR), som gjelder i Norge gjennom personopplysningsloven, og Datatilsynet er tilsynsmyndighet. Lagring og lesing av informasjon på brukerens enhet (cookies, localStorage) reguleres av ekomloven § 3-15, i kraft fra 1. januar 2025. Den krever informasjon og et samtykke som oppfyller kravene i GDPR, unntatt for lagring som bare skal overføre kommunikasjon eller som er strengt nødvendig for en tjeneste brukeren uttrykkelig har bedt om.

Hold beaconet slankt:

• Samle inn metrikken, ikke personen: metrikknavn, verdi, maltype, land, enhetsklasse. Du trenger ingen IP-adresse for å beregne 75. persentil av LCP.
• Fjern query string før sending, og behold bare stien.
• Ikke sett en cookie bare for å koble besøk sammen. Du mister skillet mellom nye og gjentatte sesjoner, men telemetrien er ikke lenger avhengig av samtykke til lagring på enheten.
• Konfigurer collectoren slik at IP-adresser ikke lagres, eller forkortes ved mottak.
• Lagrer leverandøren data i USA, sjekk om datalagring i EU/EØS er tilgjengelig, og at en databehandleravtale er signert.

Dette er ikke juridisk rådgivning; personvernombudet ditt trekker grensen for ditt oppsett.

#Slik stopper du trege releaser med Lighthouse CI

Lighthouse CI kjører Lighthouse mot preview- eller staging-URL-er i pipelinen og sammenligner resultatene med assertions du definerer. Som standard kjører lhci collect Lighthouse tre ganger per URL (numberOfRuns), noe som jevner ut enkeltkjøringer med støy. Hver assertion har et nivå: warn skriver ut resultatet uten å feile, mens error får kommandoen til å avslutte med en kode ulik null, og det er det som får bygget til å feile.

Forhåndsinnstillingen lighthouse:recommended er et fornuftig utgangspunkt. Ifølge dokumentasjonen til Lighthouse CI kontrollerer den at alle revisjoner utenfor ytelse fikk full poengsum, og varsler når metrikkverdiene faller under en poengsum på 90. Revisjoner som ikke passer prosjektet, slår du av én og én. Legg til eksplisitte grenser for det teamet ditt styrer direkte, for eksempel samlet vekt av JavaScript og CSS på malene som gir omsetning.

Lighthouse kjører i laboratoriet, så tallene vil ikke stemme med CrUX. Bruk det til å sammenligne ett bygg med det forrige under like forhold, ikke til å forutsi feltverdier.

#Visuelle regresjonstester med Playwright

Ytelse handler også om stabilitet. En plugin-oppdatering som plutselig forskyver layouten på mobil, skader både CLS og konverteringer.

Playwright har denne kontrollen innebygd som assertion toHaveScreenshot. Første kjøring genererer referanseskjermbilder; senere kjøringer sammenlignes med dem. Etter en tilsiktet designendring genererer du baseline på nytt med npx playwright test --update-snapshots. Innstillingen maxDiffPixels angir hvor mange piksler som kan avvike før testen feiler. Dokumentasjonen til Playwright advarer også om at renderingen varierer med operativsystem, nettleserversjon, innstillinger og maskinvare, så generer baselines i samme miljø som testene kjører i, vanligvis CI-containeren og ikke en utviklers bærbare.

Det praktiske oppsettet er beskjedent: skjermbilder av malene som gir omsetning (forside, kategori, produkt, handlekurv, checkout) i tre viewport-bredder. Små avvik innenfor toleransen går gjennom; større venter på en menneskelig beslutning i pull requesten.

#Slik bruker du Query Monitor og Nettstedshelse til WordPress-diagnostikk

Query Monitor av John Blackbourn er standard diagnose-plugin for én enkelt forespørsel. For hver sidevisning lister den databasespørringene og markerer trege, dupliserte eller feilaktige spørringer, viser PHP-feil med ansvarlig komponent og kallstakk, og lister HTTP API-forespørsler med svarkode, ansvarlig komponent og tidsbruk. Den dekker også hooks og actions, malhierarkiet, innlastede skript og stiler og oppdateringer av transients. Som standard er utdataene bare synlige for administratorer på enkeltnettsteder og superadministratorer i Multisite; en autentiseringscookie kan utvide tilgangen til andre brukere.

Vi bruker Query Monitor på staging til diagnostikk, ikke som kontinuerlig produksjonsovervåking: den forklarer én forespørsel i dybden, mens en APM-agent samler alle.

Nettstedshelse (Verktøy, Nettstedshelse) legger til et gratis lag med tidlig varsling. Statusfanen grupperer funnene i kritiske problemer, anbefalte forbedringer og beståtte tester. Siden WordPress 6.6 melder Nettstedshelse et kritisk problem når den samlede størrelsen på automatisk lastede alternativer overstiger 800 KB, som beskrevet i utviklernotatet for WordPress 6.6 om autoload-alternativer. Den samme versjonen slutter som standard å laste enkeltalternativer større enn 150 000 byte automatisk, en egen grense som styres av filteret wp_max_autoloaded_option_size. Oppblåste autoload-data lastes ved hver forespørsel, så denne kontrollen er verdt å lese etter hver plugin-gjennomgang.

#APM for WordPress med PHP-agenten fra New Relic

En APM-agent registrerer hver forespørsel i produksjon og viser hvor tiden gikk. WordPress-støtten i PHP-agenten fra New Relic er et godt eksempel på instrumentering som forstår WordPress:

• newrelic.framework.wordpress.hooks er aktivert som standard fra agentversjon 5.3; settes den til false, slås de WordPress-spesifikke metrikkene av.
• Hook-metrikker viser tiden brukt i hver WordPress-hook, målt fra apply_filters, apply_filters_ref_array, do_action og do_action_ref_array.
• Plugin- og temametrikker viser tiden brukt i hver plugin og hvert tema, noe som besvarer “hvilken plugin gjorde denne siden treg” uten gjetting.
• Fra agentversjon 10.16 styrer newrelic.framework.wordpress.hooks.options hvor mye som registreres. I modusen threshold registrerer agenten bare hooks som er tregere enn newrelic.framework.wordpress.hooks.threshold, som er 1 ms som standard. Det holder overhead og datamengde nede på travle nettsteder.

Datadog, Tideways og Blackfire dekker lignende områder med egne agenter. Valget avhenger som regel av hva resten av organisasjonen allerede bruker, fordi ett verktøy for alle tjenester slår et bedre verktøy som ingen andre leser.

#Slik tracer du WordPress med OpenTelemetry PHP

OpenTelemetry er det leverandørnøytrale alternativet: de samme tracene kan gå til Grafana Tempo, Jaeger eller en kommersiell backend. Dokumentasjonen for automatisk PHP-instrumentering krever PHP 8.0 eller nyere og utvidelsen installert med pecl install opentelemetry. Konfigurasjonen gjøres med miljøvariabler:

OTEL_PHP_AUTOLOAD_ENABLED=true
OTEL_SERVICE_NAME=wordpress-shop
OTEL_TRACES_EXPORTER=otlp
OTEL_EXPORTER_OTLP_ENDPOINT=http://collector:4318

For WordPress finnes en egen pakke, open-telemetry/opentelemetry-auto-wordpress, som installeres med composer require open-telemetry/opentelemetry-auto-wordpress. WordPress-kjernen bruker ikke Composer, så README-filen til pakken viser hvordan Composer-autoloaderen lastes før WordPress starter, for eksempel med php_value auto_prepend_file /var/www/vendor/autoload.php i Apache. Instrumenteringen kan slås av igjen med OTEL_PHP_DISABLED_INSTRUMENTATIONS=wordpress.

For enkeltstående profilering fra terminalen trenger WP-CLI-kommandoen wp profile ingen plugin. Du installerer den med wp package install wp-cli/profile-command; deretter måler wp profile stage fasene bootstrap, main query og template, wp profile hook actions og filtre, og wp profile queries databasespørringene. Den fungerer på servere der du ikke får installere plugins. Xdebug gir den mest detaljerte profilen av alle, og overheaden holder den på lokale maskiner.

#Hvilke database- og objektcache-metrikker du bør overvåke

MySQL slow query log er slått av som standard. Den logger setninger som tar lengre tid enn long_query_time sekunder og undersøker minst min_examined_row_limit rader. Standardverdien for long_query_time er 10 sekunder, altfor romslig for en webforespørsel; minimum er 0, og verdien kan angis med mikrosekunders oppløsning. Hver oppføring har Query_time, Lock_time, Rows_sent og Rows_examined, og et stort gap mellom undersøkte og sendte rader er det klassiske tegnet på en manglende indeks, typisk på wp_postmeta bak produktfiltre. log_queries_not_using_indexes tar med spørringer uten indeks i loggen, og log_throttle_queries_not_using_indexes begrenser hvor raskt de skrives. mysqldumpslow oppsummerer loggfilen. Hvordan du retter det loggen finner, står i vår guide til optimalisering av WordPress-databasen.

For en Redis-objektcache gir kommandoen INFO rådata:

• keyspace_hits og keyspace_misses: vellykkede og mislykkede nøkkeloppslag. Treffraten er treff delt på treff pluss bom.
• evicted_keys: nøkler fjernet på grunn av grensen maxmemory. Et stigende tall betyr at cachen er for liten for arbeidssettet.
• mem_fragmentation_ratio: forholdet mellom used_memory_rss og used_memory.

Det finnes ingen universelt “god” treffrate, fordi den avhenger av hvor mye av nettstedet som kan caches. Registrer din egen baseline etter en ren utrulling og varsle ved et vedvarende fall: det betyr som regel at en ny plugin går utenom cachen, at en konfigurasjon er endret, eller at trafikken har flyttet seg til sider uten cache.

#Slik overvåker du headless WordPress

Når WordPress bare er innholds-API-et og frontenden kjører på Astro eller Next.js, er det to systemer å følge med på. I backend: svartid og andel 5xx-feil for endepunktene i REST API eller WPGraphQL. I frontend: byggetid, regenereringstid for sider og kostnaden ved hydrering i nettleseren.

En distribuert trace binder de to sammen. Anbefalingen W3C Trace Context definerer headerne traceparent og tracestate, som bærer en trace-ID fra frontenden til WordPress-API-et, og OpenTelemetry støtter dem for kontekstpropagering. Én forespørsel blir da synlig gjennom CDN, frontend, WordPress-API, MySQL og Redis. Uten dette ser hvert team bare sin egen del, og hver treg forespørsel ser ut som nabolagets feil.

#Avviksdeteksjon for nettstedets ytelse

Faste terskler som “varsle meg hvis LCP passerer 2,5 s” slår enten til for sent eller gir falske alarmer under trafikktopper. Dynamiske baselines lærer hva som er normalt for hver time og ukedag, og melder avvik før en hard grense nås. De fleste APM- og observability-plattformer tilbyr dette; selve innstillingen betyr mindre enn konteksten ved siden av.

Et avvik er bare nyttig når du ser hva som endret seg ved siden av det. Marker utrullinger, plugin-oppdateringer og kampanjestarter på samme tidslinje som metrikkene: Grafana gjør dette med annotations, New Relic med deployment-markører. En TTFB-topp rett ved siden av en plugin-oppdatering avslutter feilsøkingen før den begynner.

#Slik setter du et ytelsesbudsjett for Core Web Vitals

Et budsjett er et sett øvre grenser der det å passere én har en avtalt konsekvens. Googles “gode” terskler ved 75. persentil er gulvet: LCP innen 2,5 s, INP innen 200 ms, CLS innen 0,1, ifølge web.dev. Enterprise-team setter som regel strengere mål per prosjekt, pluss grenser for levert JavaScript og CSS som kontrolleres i Lighthouse CI-porten.

Et budsjett uten eier forvitrer. Utnevn én person som går gjennom trenden hver uke, avgjør om en terskel fortsatt gir mening, og kan si nei til en release. Rut også varslene etter alvorlighet: en ødelagt checkout varsler vakthavende, en langsom TTFB-økning går til en teamkanal, og små avvik venter på ukerapporten. Hvis hvert varsel vekker noen, leser ingen dem etter en måned.

#Hvordan sidehastighet påvirker konverteringsraten

Det nyttige spørsmålet for ledelsen er ikke “hvor mange millisekunder”, men “hva koster en tregere side oss”. Svar med egne data i stedet for en prosentsats hentet fra et annet selskaps casestudie. Send RUM-verdiene til samme analyselager som konverteringshendelsene dine, grupper sesjonene etter LCP- eller INP-bånd, og sammenlign konverteringen per gruppe. Resultatet gjelder ditt publikum og din checkout, og det er den versjonen en finansdirektør godtar når du ber om en ytelsessprint.

#Hva en tjeneste for WordPress-overvåking omfatter

Hos WPPoland dekker overvåkingsarbeidet tre ting.

1. Design av fullstack-overvåking: RUM, syntetiske tester og APM eller OpenTelemetry-traces koblet sammen i én visning, slik at én hendelse er synlig fra nettleseren ned til SQL-spørringen.
2. Forebygging av regresjoner: portene med Lighthouse CI og Playwright som stopper trege eller ødelagte maler før de når produksjon.
3. Rapporter man kan handle på: metrikker oversatt til beslutningene ledelsen må ta, med en eier for hvert budsjett.

Verktøy og implementering prises individuelt, fordi kostnaden avhenger av antall nettsteder, trafikkvolum og valgt leverandør.

#Hvor du begynner med ytelsesovervåking av WordPress

Start smått og i rekkefølge. Først feltdata fra ekte brukere med web-vitals-biblioteket, fordi de viser hva besøkende faktisk opplever, og Query Monitor på staging. Deretter Lighthouse CI og Playwright-kontroller i pipelinen, pluss syntetiske tester av brukerreiser fra regionene du selger i. Så APM eller OpenTelemetry-traces og slow query log på endepunktene de to første lagene peker på. Hvert lag svarer på et spørsmål det forrige reiser, og et varsel uten eier er støy.

Når overvåkingen viser hvor tiden går, kommer rettingene etterpå. Vår guide til WordPress-optimalisering og hastighet dekker server, caching og frontend, og guiden til INP-optimalisering går dypere inn i interaktivitetsmetrikken. En bredere oversikt gir den store guiden til WordPress-ytelse og Core Web Vitals. For en praktisk gjennomgang av nettstedet ditt, se hvordan gjøre en WordPress-basert nettside raskere.