Prestanda och Användbarhet Förklarat

Hastighet och användbarhet är inte kosmetik; de påverkar tillit, konvertering och driftskostnad.

English Svenska Español

Målgrupp: Sajtägare / marknad / drift

Tillbaka till docs

Vad som är viktigt för icke-tekniska team

Långa laddtider tappar uppmärksamhet och förtroende. Instabila sidor ökar supporttryck och checkout-avhopp.

En förutsägbar användarresa ökar ofta avslutade köp och minskar manuella supportärenden.

Vad projektet redan gör

Mäter och lagrar runtime- och web-vitals-data från anslutna sajter.

Visar rekommendationer med tydlig koppling till effekt och åtgärd.

Vad team kan göra varje vecka

Granska fallerande checks, välj två toppåtgärder, kör heartbeat igen och jämför trend på tenant/peer-sidor.

Följ non-200-händelser och fallback-vägar för att minska dolda regressionsproblem.

Standardtider och regler för cache (per 30 mars 2026)

GraphQL edge-cache kör 60 sekunder färsk + 120 sekunder stale-while-revalidate som standard (GRAPHQL_EDGE_CACHE_TTL_SECONDS, GRAPHQL_EDGE_CACHE_STALE_SECONDS).

Meny-snapshot-cache är 5 minuter, URI-existenskontroll för meny är 5 minuter, och sitemap-path-cache är 10 minuter (MENU_SNAPSHOT_TTL_MS, MENU_URI_CHECK_TTL_MS, MENU_SITEMAP_TTL_MS).

Storefront GraphQL capability-probe kör var 15:e minut (STOREFRONT_GRAPHQL_PROBE_TTL_MS). /shop använder ISR med revalidate 300 sekunder, medan många innehållsfrågor kör 1800 sekunder.

Uppdatera cache efter ändringar i schema/meny/taxonomi, efter deploy av routelogik, eller när non-200/fallback-trender ökar.

Effekt av refresh nu jämfört med att vänta på TTL

Refresh nu: besökare ser korrigerat innehåll och rutter direkt, och diagnostik synkas snabbare efter ändring.

Refresh nu har också en kostnad: tillfälligt högre origin-belastning när fler cache-missar går till WordPress/GraphQL samtidigt.

Vänta på TTL: lägre omedelbar backend-belastning, men besökare kan se stale menyer, stale innehåll eller blandat gammalt/nytt beteende tills tiderna löper ut.

Praktisk regel: refresh direkt efter strukturella ändringar; låt TTL passera naturligt för små textjusteringar.

Använd cachekontroller och purge efter ändringar i innehållsmodell.
Validera menyer/rutter före publicering för att undvika blindgator.
Håll diagnostik synlig i planeringen så kvalitetsarbete inte skjuts upp.
Använd Server-Timing-headern (app_ms, wp_ms, menu_ms) för att hitta latenskällan innan du ändrar inställningar.

Cache-refresh kommando (WP-CLI)

wp cache flush && wp transient delete --all

Kör på WordPress-värden efter ändringar i innehållsmodell, meny eller schema.

Mermaid-diagram

flowchart LR U[Besokarens request] --> SF[StoreFront worker] SF --> MC[Menu snapshot-cache 5m] SF --> GC[GraphQL edge-cache 60s + SWR 120s] GC --> WP[WordPress GraphQL] U --> WV[Web vitals beacon i browser] WV --> HB[Heartbeat och diagnostikpayload] HB --> RP[RAGBAZ tenant- och peer-rapporter] RP --> ACT[Valj fix och cache-refresh-atgard] ACT --> NX[Nasta requests validerar forbattrade varden]