Mobile-first-ytelse: optimaliseringsstrategier for mobilindeksering 2026

Google indekserer og rangerer mobilversjonen av en side, hentet av søkemotorens smarttelefon-crawler. Et WordPress-nettsted som bare krymper et desktop-oppsett til telefonbredde, kan se greit ut ved en rask sjekk og likevel sende en tung, treg side til nettopp den enheten som avgjør hvordan siden indekseres. Mobile-first-ytelse betyr å bygge hver side for en telefon på et begrenset nett først, og deretter legge til vekt for større skjermer bare der den gjør nytte for seg.

Les mer om hastighetsoptimalisering av WordPress hos WPPoland.

Denne guiden tar for seg hva Googles mobile-first-indeksering krever, terskelverdiene for Core Web Vitals på mobil, hvordan mobilhastighet måles i laboratoriet og i felten, og hvilke funksjoner og kodemønstre i WordPress som forbedrer LCP, INP, CLS og tilbakenavigering på telefoner.

#Tidslinje for mobile-first-indeksering fra 2016 til 2024

Googles beste praksis for mobile-first-indeksering definerer begrepet på én linje: Google bruker mobilversjonen av innholdet på et nettsted, gjennomsøkt med smarttelefon-agenten, til indeksering og rangering. Det tok åtte år å få hele nettet over.

I innlegget fra oktober 2023 beskrev John Mueller og Nir Kalush den lille gruppen nettsteder som fortsatt ble gjennomsøkt med desktop-crawleren. Feilene var sider som viser feil til alle mobilbrukere, en mobilversjon som er blokkert i robots.txt mens desktop-versjonen fortsatt kan gjennomsøkes, og mobilsider som alle videresender til forsiden. I juni 2024 skrev Mueller at et nettsted der innholdet ikke kan nås med en mobil enhet i det hele tatt, ikke lenger ville kunne indekseres etter 5. juli 2024. Googlebot Desktop dukker fortsatt opp i serverlogger for enkelte funksjoner, for eksempel produktoppføringer og Google for Jobs, så en desktop-brukeragent i tilgangsloggen betyr ikke at nettstedet ditt ble hoppet over.

Den såkalte mobilindeksen for 2026 er altså ingen ny indeks. Overgangen skjedde i 2023 og 2024. Det som stadig endrer seg, er innholdet på mobilsidene dine og hvor raske de er for ekte besøkende.

#Hva Googles mobile-first-dokumentasjon ber WordPress-nettsteder sjekke

Siden med beste praksis er en sjekkliste for likhet. Mobilversjonen av en side skal samsvare med desktop-versjonen når det gjelder:

• hovedinnholdet, inkludert tekst, bilder og video
• strukturerte data
• title-elementet og metabeskrivelsen
• alt-tekst på bilder
• robots-metakoder
• overskrifter

Den samme siden advarer mot lat lasting av primærinnhold som bare vises etter en brukerhandling som et trykk eller en sveipebevegelse, fordi crawleren ikke utfører slike handlinger. I WordPress er de vanlige synderne faner eller trekkspillmenyer som henter innholdet sitt med AJAX ved klikk, og egne mobilmaler fra eldre mobilutvidelser som fjerner seksjoner, schema eller alt-tekst. Et responsivt tema som sender samme HTML til alle enheter, består likhetssjekken av natur. Det er én grunn til å være forsiktig med enhetsspesifikk HTML, som omtales i avsnittet om Client Hints nedenfor.

#Terskelverdier for Core Web Vitals på mobil i 2026

De gjeldende terskelverdiene er:

Siden mars 2024 har måltallet for responsivitet vært Interaction to Next Paint. Rick Viscomis lanseringsinnlegg på web.dev kunngjorde INP som en stabil Core Web Vital som erstatter First Input Delay, og ga utviklere frist til 9. september 2024 med å gå bort fra FID. En guide som fortsatt oppgir FID som Core Web Vital, er eldre enn denne endringen.

Hver terskel vurderes ved 75. persentil av sidelastinger, delt opp på mobil og desktop (web.dev, Web Vitals). Mobil og desktop er separate populasjoner, så et raskt resultat på desktop sier ingenting om resultatet på telefon.

Mange team setter interne mål under grensen for «bra» for å ha en buffer, fordi feltdata svinger med trafikkmiks, kampanjer og tredjepartsskript. Googles egen dokumentasjon om sideopplevelse legger til en advarsel: å jage en perfekt poengsum bare av SEO-hensyn er kanskje ikke den beste bruken av tiden din.

#Hvordan Google bruker signaler for sideopplevelse i rangeringen

Googles dokumentasjon om sideopplevelse svarer direkte på spørsmålet om rangering:

• Det finnes ikke ett enkelt signal for sideopplevelse. Kjernesystemene for rangering ser på en rekke signaler.
• Core Web Vitals brukes av Googles rangeringssystemer.
• Utover Core Web Vitals hjelper ikke andre aspekter ved sideopplevelsen direkte et nettsted til å rangere høyere, selv om de gjør nettstedet mer tilfredsstillende å bruke.
• Sideopplevelse vurderes vanligvis per side, med enkelte vurderinger for hele nettstedet.
• Google viser fortsatt det mest relevante innholdet når sideopplevelsen er svak. En god opplevelse hjelper der mange sider er omtrent like nyttige.

For mobilarbeid setter dette prioriteringene. Størrelse på trykkflater, en ryddig mobilmeny og bfcache-kvalifisering er verdt å gjøre for de besøkende og for Core Web Vitals som de påvirker, men Google beskriver dem ikke som egne rangeringssignaler. Den samme siden oppgir ikke noe krav om AMP: selvvurderingen dekker Core Web Vitals, HTTPS, visning på mobile enheter, annonser, påtrengende interstitialer og et tydelig hovedinnholdsområde.

#Hvordan teste mobilhastighet i laboratoriet og i felten

#Innstillinger for mobilemulering i Lighthouse

Lighthouse emulerer i standard mobilkjøring en Moto G Power (2022) med et visningsområde på 412 ganger 823 piksler, angitt i Lighthouse sine konfigurasjonskonstanter. Dokumentasjonen om struping oppgir nettverksprofilen som 150 ms forsinkelse, 1,6 Mbps ned og 750 Kbps opp, merket «Slow 4G» og beskrevet som omtrent den nederste fjerdedelen av 4G-tilkoblinger. CPU-strupingen bruker en fast multiplikator på 4x, ment å flytte en kraftig stasjonær maskin ned i klassen for mobiler i mellomsjiktet. På en tregere bærbar PC blir denne multiplikatoren for kraftig, så sjekk verdien «CPU/Memory Power» nederst i rapporten før du sammenligner kjøringer fra ulike maskiner.

• Lighthouse (Chrome DevTools): mobilemulering med struping av CPU og nettverk
• PageSpeed Insights: data fra ekte brukere (CrUX) pluss en laboratoriekjøring i Lighthouse
• WebPageTest: tester på ekte enheter fra ulike steder

#Feltdata fra CrUX og Search Console

Feltdata er det vurderingen av Core Web Vitals bygger på. CrUX-metodikken samler bare inn data fra Chrome-brukere som har slått på rapportering av bruksstatistikk og synkroniserer nettleserloggen, og Chrome på iOS er utelatt. Safari er ikke Chrome, så den bidrar heller ikke med noe. Et nettsted der mobilpublikummet stort sett bruker iPhone, får mobilscoren fra felten fra de besøkende som bruker Android.

• Chrome User Experience Report (CrUX): data fra ekte Chrome-brukere
• Google Search Console (rapporten Core Web Vitals): grupper for mobil og desktop for dine egne URL-er
• RUM (Real User Monitoring): verktøy som SpeedCurve, Calibre eller New Relic for kontinuerlig overvåking på tvers av alle nettlesere

#Hvilke ekte telefoner du bør teste på

Ingen emulator gjenskaper en ekte enhet fullt ut. Ha minst disse tilgjengelige for testing:

• en smarttelefon i mellomklassen (Moto G eller Samsung Galaxy A)
• en nyere toppmodell (iPhone eller Pixel)
• et nettbrett (iPad eller Samsung Tab)

#Adaptiv lasting etter enhet i WordPress

Adaptiv lasting leverer ulike vektklasser av samme side, avhengig av hva den besøkendes enhet klarer.

#Hvordan oppdage enhetens kapasitet med JavaScript

// Oppdag enhetens kapasitet, med standardverdier der et API mangler
const getDeviceCapabilities = () => {
  return {
    // CPU-kjerner
    cores: navigator.hardwareConcurrency || 4,
    // Omtrentlig minne i enheten i GB (ikke tilgjengelig i alle nettlesere)
    memory: navigator.deviceMemory || 4,
    // Effektiv tilkoblingstype
    connection: navigator.connection?.effectiveType || '4g',
    // Ønske om redusert databruk
    saveData: navigator.connection?.saveData || false,
  };
};

MDN merker navigator.deviceMemory som begrenset tilgjengelig, ikke Baseline, tilgjengelig bare over HTTPS og bevisst unøyaktig: verdien rundes av til en potens av to for å gjøre fingeravtrykk vanskeligere. Behandle den som et hint med en trygg standardverdi. Valg av bildeformat krever ingen deteksjon i det hele tatt, fordi picture-elementet som vises nedenfor, lar nettleseren selv velge AVIF eller WebP.

#Hva du bør levere til telefoner i topp-, mellom- og lavklassen

Basert på den oppdagede kapasiteten:

Enheter i toppklassen (8+ kjerner, 8+ GB RAM, rask tilkobling):

• AVIF-bilder i full kvalitet
• komplett JavaScript med animasjoner
• bredere spekulativ lasting av sannsynlige neste sider
• videobakgrunner der de tjener innholdet

Enheter i mellomklassen (4 til 6 kjerner, 4 til 6 GB RAM, 4G):

• bilder i middels kvalitet
• redusert JavaScript, enkle CSS-animasjoner
• spekulativ lasting bare for hovedlenker
• statiske bilder i stedet for videobakgrunner

Enheter i lavklassen (2 til 4 kjerner, under 4 GB RAM, treg tilkobling eller Save-Data):

• hardt komprimerte bilder
• bare nødvendig JavaScript
• ingen spekulativ lasting, for å spare båndbredde
• et forenklet oppsett uten visuelle effekter

#Client Hints, Accept-CH og sidebuffering i WordPress

Med Client Hints kan serveren ta den samme avgjørelsen før den sender HTML. Nettleseren sender dem ikke uoppfordret. Ifølge MDNs guide til Client Hints oppgir serveren hvilke hint den vil ha i en Accept-CH-svarheader, og nettleseren tar dem med i påfølgende forespørsler. Den første sidevisningen fra en ny besøkende kommer derfor uten dem. Bare hintene med lav entropi (Save-Data, Sec-CH-UA, Sec-CH-UA-Mobile og Sec-CH-UA-Platform) kan sendes som standard. Minnet i enheten sendes som Sec-CH-Device-Memory, og nettverkskvaliteten som ECT, RTT og Downlink.

// 1. Be nettleseren om hint om enhet og nettverk i senere forespørsler
add_action('send_headers', function () {
    header('Accept-CH: Sec-CH-Device-Memory, ECT');
    header('Vary: Sec-CH-Device-Memory', false);
});

// 2. Les hintene og velg et ytelsesnivå
function device_aware_content_strategy() {
    $memory = isset($_SERVER['HTTP_SEC_CH_DEVICE_MEMORY'])
        ? (float) $_SERVER['HTTP_SEC_CH_DEVICE_MEMORY']
        : null;

    $ect = $_SERVER['HTTP_ECT'] ?? null;

    if ($memory && $memory >= 8 && $ect === '4g') {
        define('WP_DEVICE_TIER', 'high');
    } elseif (($memory && $memory <= 2) || in_array($ect, ['slow-2g', '2g'], true)) {
        define('WP_DEVICE_TIER', 'low');
    } else {
        define('WP_DEVICE_TIER', 'medium');
    }
}
add_action('init', 'device_aware_content_strategy');

Det er på bufringssiden at tilpasning på serveren vanligvis bryter sammen. En utvidelse for helsidebuffer eller et CDN lagrer én kopi av HTML-en per URL, med mindre buffernøkkelen inkluderer hintet. Uten det får alle som kommer etter den første besøkende, nivået som ble valgt for denne. MDN anbefaler å oppgi hintene som endrer et svar, i Vary-headeren, og advarer om at hint med mange mulige verdier, som Downlink og RTT, i praksis gjør et svar umulig å bufre. For de fleste WordPress-nettsteder er den tryggere fordelingen å holde HTML-en identisk for alle enheter, la srcset og sizes velge bildefiler, og gjøre JavaScript-tilpasningen på klienten. Det bevarer også den innholdslikheten som Googles mobile-first-dokumentasjon ber om.

#Hvordan forbedre LCP på mobil

Largest Contentful Paint er som regel det vanskeligste måltallet å forbedre på mobil, fordi det avhenger av nettverket, prosessoren og innholdets størrelse på én gang.

#Hvilket element som er LCP på mobil

På de fleste WordPress-sider er LCP-elementet på mobil ett av disse:

• hovedbildet eller fremhevet bilde i innlegget
• et bannerbilde i en slider
• den første lange tekstblokken, på sider uten bilder

#Delene av LCP og hvor tiden går

web.devs guide til optimalisering av LCP deler måltallet i fire deler: tid til første byte, forsinkelse i ressurslasting (fra TTFB til nettleseren begynner å laste LCP-ressursen), varighet av ressurslastingen, og forsinkelse i elementgjengivelsen (fra nedlastingen er ferdig til elementet er fullt gjengitt). Guidens budsjett er at mesteparten av tiden skal gå til å laste HTML-dokumentet og LCP-ressursen, omtrent 40 prosent hver, mens hver av de to forsinkelsene holder seg under 10 prosent. En lang forsinkelse i ressurslastingen betyr nesten alltid at nettleseren fant bildet sent. Den samme guiden nevner et LCP-bilde satt som CSS-bakgrunn som et tilfelle der forhåndslastingsskanneren ikke kan oppdage det i HTML-en, og sier at LCP-bildet aldri skal lastes lat.

#Hvordan gjøre LCP raskere med forhåndslasting, format og bildestørrelse

Forhåndslast LCP-ressursen:

<link rel="preload" as="image" href="/images/hero-mobile.avif"
      type="image/avif" fetchpriority="high">

Fjern oppdagelseskjeder: Nettleseren bør finne LCP-ressursen så tidlig som mulig:

1. HTML-en lastes ned (TTFB)
2. LCP-ressursen oppdages i HTML-en
3. Nedlastingen av ressursen starter

Hvis hovedbildet ditt er referert i et eksternt stilark som background-image, oppdager ikke nettleseren det før den har lastet ned og tolket CSS-en. Legg et <img> direkte i HTML-en med fetchpriority="high".

Optimalt bildeformat:

<picture>
  <source srcset="/images/hero-400.avif 400w,
                  /images/hero-800.avif 800w"
          type="image/avif" sizes="100vw">
  <source srcset="/images/hero-400.webp 400w,
                  /images/hero-800.webp 800w"
          type="image/webp" sizes="100vw">
  <img src="/images/hero-800.jpg"
       alt="Relevant beskrivelse"
       width="800" height="450"
       fetchpriority="high"
       decoding="async">
</picture>

Bildestørrelser for mobil: Ikke send den samme filen til telefoner og stasjonære maskiner. En telefonskjerm som er 400 piksler bred, trenger ikke et bilde på 1920 piksler (mer i vår guide til bildeoptimalisering og kritisk CSS):

// Legg til bildestørrelser for mobiloppsett
function add_mobile_image_sizes() {
    add_image_size('mobile-hero', 480, 270, true);
    add_image_size('mobile-thumbnail', 320, 180, true);
}
add_action('after_setup_theme', 'add_mobile_image_sizes');

#Funksjoner i WordPress-kjernen for responsive bilder og lat lasting

Mye av bildearbeidet over finnes allerede i WordPress-kjernen, og en utvidelse som gjentar det, kan komme i veien.

• WordPress 4.4 (2015): srcset og sizes. Joe McGills utviklernotat forklarer at WordPress legger til srcset og sizes i bildemarkeringen den genererer, slik at nettleseren kan laste ned den mest passende størrelsen. Standardverdien for sizes forutsetter at bildet vises i sin egen bredde opptil full bredde på visningsområdet, og notatet ber temaer justere den med filteret wp_calculate_image_sizes (wp_calculate_image_srcset endrer listen over kandidater). Filteret max_srcset_image_width begrenser hvilke bredder som tas med, til 1600 piksler som standard. Den samme versjonen la til størrelsen medium_large, 768 piksler bred uten høydebegrensning, som bare genereres for nye opplastinger eller når størrelser genereres på nytt.
• WordPress 5.5: innebygd lat lasting. Attributtet loading styres av wp_lazy_loading_enabled, introdusert i 5.5 og slått på for iframes som standard siden 5.7.
• WordPress 6.3: attributter for lasteoptimalisering. wp_get_loading_optimization_attributes avgjør om et bilde får loading="lazy", fetchpriority="high" eller decoding="async". Den rører ikke attributter som allerede finnes, og gir en advarsel hvis et element ville fått både lat lasting og høy prioritet. Siden 7.0 godtar den også fetchpriority="low" og fetchpriority="auto", slik at lat lasting ikke legges til.

Den praktiske sjekken gjøres i den gjengitte HTML-en til en ekte side i et telefonvisningsområde: hovedbildet skal ha fetchpriority="high" og ingen loading="lazy", og sizes-verdien skal samsvare med plassen bildet faktisk tar i mobiloppsettet. Et tema som skriver ut hovedbildet som CSS-bakgrunn, hopper over alt dette.

#Spekulativ lasting i WordPress 6.8

WordPress 6.8 slo på spekulativ lasting gjennom nettleserens Speculation Rules API. Felix Arntz’ utviklernotat beskriver standardinnstillingene:

• Funksjonen er slått på i frontend på alle nettsteder, unntatt for innloggede brukere og nettsteder der pene permalenker er slått av.
• URL-er forhåndshentes med konservativ iver, som utløses når en bruker begynner å klikke på en lenke.
• URL-er med spørringsparametere utelates automatisk, noe som dekker de fleste såkalte action URLs som endrer tilstand ved en GET-forespørsel.
• Chrome, Edge og Opera støtter API-et; andre nettlesere ignorerer det, så ingenting slutter å virke.

Notatet oppgir at funksjonsutvidelsen kjørte på over 50 000 nettsteder før sammenslåingen, og at nettsteder som brukte den, forbedret andelen som besto LCP med omtrent 1,9 prosent i medianen, målt med data fra HTTP Archive og CrUX. På mobil, der trykk på tilbake og fremover og trykk på lenker er hele navigasjonsmodellen, betyr dette mer enn på desktop. Utvidelser med egne handlingsstier, for eksempel en handlekurv, bør utelate dem:

add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $href_exclude_paths ) {
    $href_exclude_paths[] = '/cart/*';
    return $href_exclude_paths;
} );

#Hvordan forbedre INP på mobil

INP måler hvor raskt siden reagerer på brukerinndata. web.devs artikkel om INP regner med tre typer interaksjoner: museklikk, trykk på en berøringsskjerm og tastetrykk på et fysisk tastatur eller skjermtastatur. Hovring, zooming og rulling registreres ikke. Forsinkelsen i hver interaksjon har tre deler: inndataforsinkelse før noen hendelsesbehandler kjører, behandlingstiden til behandlerne, og presentasjonsforsinkelse frem til neste bilde tegnes. På en telefon er hver interaksjon et trykk, og prosessoren er tregere, så alle tre delene vokser.

#Hovedårsaker til dårlig INP på mobil

1. Tung JavaScript på hovedtråden: tredjepartsskript (analyse, chat, annonser) som blokkerer interaksjon.
2. Hydrering i rammeverk: React, Vue eller Angular som hydrerer komponenter etter den første lastingen.
3. Kostbare hendelsesbehandlere: lyttere som kjører tunge beregninger ved trykk.
4. Lange oppgaver: web.devs guide til optimalisering av lange oppgaver definerer en lang oppgave som enhver oppgave som tar mer enn 50 ms.

#Hvordan redusere INP ved å utsette JavaScript

Utsett JavaScript som ikke er kritisk:

<!-- Last analyse etter den første brukerinteraksjonen -->
<script>
  let analyticsLoaded = false;
  function loadAnalytics() {
    if (analyticsLoaded) return;
    analyticsLoaded = true;
    const script = document.createElement('script');
    script.src = '/analytics.js';
    document.head.appendChild(script);
  }

  // Last ved første berøring, rulling eller tastetrykk, eller etter 5 sekunder
  ['touchstart', 'scroll', 'keydown'].forEach(event => {
    document.addEventListener(event, loadAnalytics, { once: true, passive: true });
  });
  setTimeout(loadAnalytics, 5000);
</script>

Bruk requestIdleCallback til arbeid som ikke haster:

// Kjør ikke-kritisk arbeid mens nettleseren er ledig
requestIdleCallback((deadline) => {
  while (deadline.timeRemaining() > 0) {
    processNonCriticalTask();
  }
});

Gi fra deg kontrollen inne i hendelsesbehandlere:

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

button.addEventListener('click', async () => {
  showSpinner();        // synlig tilbakemelding i neste bilde
  await yieldToMain();  // la nettleseren tegne først
  heavyCalculation();   // den trege delen kjører i en senere oppgave
});

Å pakke det tunge arbeidet inn i requestAnimationFrame hjelper ikke, fordi den tilbakekallingen kjører rett før neste tegning og fortsatt holder bildet tilbake. Når du gir fra deg kontrollen, deles arbeidet opp slik at nettleseren først kan tegne responsen på trykket. Guiden om lange oppgaver nevner at scheduler.yield() støttes i Chrome og Edge 129 og Firefox 142, men ikke i Safari, og det er derfor reserveløsningen med setTimeout er der.

#Hvordan forhindre CLS på mobil i WordPress

Cumulative Layout Shift (CLS) gjør mest skade på en telefon, der skjermen er liten og enhver bevegelse synes. På en telefon er et skift på 10 piksler langt mer forstyrrende enn på en 27-tommers skjerm.

#Hva som forårsaker CLS på mobil

• bilder uten eksplisitte dimensjoner
• nettfonter som gir FOUT eller FOIT
• annonser og dynamisk innsatt innhold
• navigasjonslinjer som endrer størrelse ved rulling
• skjermtastaturet som skyver innhold

#Hvordan reservere plass til bilder, fonter og annonser

Reserver plass til bilder:

/* Bokser med fast sideforhold for bilder */
.wp-post-image {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
  object-fit: cover;
}

Forhåndslast kritiske fonter:

<link rel="preload" href="/fonts/main-font.woff2"
      as="font" type="font/woff2" crossorigin>

/* font-display: swap med en reservefont med tilpassede mål */
@font-face {
  font-family: 'MainFont';
  src: url('/fonts/main-font.woff2') format('woff2');
  font-display: swap;
  size-adjust: 98%;
  ascent-override: 95%;
  descent-override: 22%;
}

Reserver plass til annonser:

.ad-slot {
  min-height: 250px; /* Forventet annonsehøyde */
  background: #f5f5f5;
  contain: layout;
}

#Hvordan gjøre WordPress-sider klare for bfcache

Tilbake/fremover-bufferen holder et komplett øyeblikksbilde av en side i minnet, inkludert JavaScript-heapen, slik at et steg tilbake gjenoppretter siden nesten umiddelbart uten å gå via nettverket. Philip Walton og Barry Pollards guide til bfcache på web.dev viser til bruksdata fra Chrome som viser at 1 av 5 navigeringer på mobil er en navigering tilbake eller fremover, mot 1 av 10 på desktop. Alle store nettlesere har en bfcache, Chrome siden versjon 96.

#Hva som blokkerer bfcache

• unload-lyttere. På desktop gjør Chrome og Firefox en side med en unload-lytter ukvalifisert. På mobil prøver Chrome og Safari fortsatt å bufre slike sider, men behandleren blir upålitelig. Bruk pagehide i stedet; Lighthouse har en no-unload-listeners-revisjon som også fanger opp tredjepartskode.
• Cache-Control: no-store på HTML-en. Nettlesere har historisk nektet å legge slike sider i bfcache. For innhold som må holde seg ferskt, men som ikke er sensitivt, anbefaler guiden no-cache eller max-age=0, som ikke påvirker kvalifiseringen.
• Referanser via window.opener. En side som er åpnet med window.open() og styres fra siden som åpnet den, kan ikke bufres. rel="noopener" unngår dette og er nå nettleserens standard for target="_blank".
• Åpne tilkoblinger. Noen nettlesere hopper over sider med en åpen IndexedDB-tilkobling, en pågående fetch() eller XMLHttpRequest, eller en åpen WebSocket- eller WebRTC-tilkobling. Guiden nevner at Chrome (fra versjon 149) og Safari ikke lenger blokkerer på grunn av åpne WebSockets. Lukk tilkoblinger ved pagehide og åpne dem igjen ved pageshow.

Mobilbrukere navigerer stadig med Tilbake-knappen. Når en side kommer tilbake fra bfcache, vises den uten en ny forespørsel.

#Hvordan sjekke om en side ble gjenopprettet fra bfcache

// Sjekk om siden ble gjenopprettet fra bfcache
window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    console.log('Page restored from bfcache');
    // Oppdater dynamisk innhold som antall i handlekurven ved behov
    refreshDynamicContent();
  }
});

Guiden anbefaler også å oppdatere utdaterte eller sensitive data ved pageshow når persisted er true, for eksempel totalsummen i handlekurven etter at brukeren endret den på en annen side.

#WordPress-innstillinger for bfcache

// Send buffer- og policyheadere før noe utdata
add_action('send_headers', function () {
    if (!is_user_logged_in()) {
        header('Cache-Control: public, max-age=300');
        // Avvis unload-behandlere, også de som legges til av tredjeparter
        header('Permissions-Policy: unload=()');
    }
});

// Fjern et utvidelsesskript som er kjent for å registrere en unload-behandler
add_action('wp_enqueue_scripts', function () {
    wp_dequeue_script('plugin-with-unload-handler');
}, 99);

Headere hører hjemme i send_headers, fordi wp_enqueue_scripts kjører inne i wp_head, etter at utdata har startet. Linjen med Permissions Policy følger rådet i bfcache-guiden for nettsteder som ikke bruker unload i det hele tatt. Chrome DevTools har en test av tilbake/fremover-bufferen i Application-panelet som oppgir nøyaktig hva som blokkerer en side.

#Trykkflater og mobilmenyer som er lette å treffe

Trykkflater betyr noe for brukervennlighet og tilgjengelighet. Google beskriver dem ikke som et rangeringssignal.

#Minste størrelse på trykkflater

• WCAG 2.2, suksesskriterium 2.5.8 (nivå AA): forklaringsdokumentet krever pekermål på minst 24 ganger 24 CSS-piksler, med unntak for avstand, en likeverdig kontroll, innebygde mål i tekst, kontroller fra brukeragenten og tilfeller der størrelsen er avgjørende. For viktige kontroller viser det til det strengere 2.5.5 Target Size (Enhanced).
• Lighthouse sine retningslinjer for trykkmål: revisjonsdokumentasjonen sier at mål på 48 ganger 48 piksler aldri feiler, og at 8 piksler mellom målene er et godt utgangspunkt.

Unntaket for innebygde mål har betydning for CSS. Lenker inne i avsnitt trenger ingen minstehøyde, så bruk størrelseskravene bare på navigasjon, knapper og skjemakontroller:

/* Minste trykkflater for kontroller, ikke for lenker inne i tekst */
nav a, button, input, select, textarea, .wp-block-button__link {
  min-height: 48px;
  min-width: 48px;
  padding: 12px;
}

#Hvordan gjøre en mobilmeny lett å trykke på

Navigasjonsmenyer på mobil krever ekstra omtanke rundt trykkflater:

.mobile-nav a {
  display: block;
  padding: 16px 24px;
  min-height: 48px;
  font-size: 16px; /* Lesbar uten zoom */
  line-height: 1.5;
}

.mobile-nav li + li {
  border-top: 1px solid #eee;
}

#Optimalisering av mobile Core Web Vitals hos WPPoland

Hos WPPoland bygger vi for enheten brukeren har i hånda, ikke for skjermen på pulten vår.

1. Adaptiv lasting: vi holder HTML-en identisk på tvers av enheter og tilpasser bilder og skript der målingene viser en gevinst.
2. Revisjon spesifikt for mobil: vi tester på ekte mobile enheter, ikke bare i emulering i nettleseren.
3. Feltdata først: vi jobber ut fra CrUX-rapporten for mobil og flytter URL-grupper fra «Dårlig» eller «Trenger forbedring» til «Bra».

#Vanlige spørsmål om mobilytelse

1. Betyr en mobilapp at jeg ikke trenger et raskt mobilnettsted? Nei. Mesteparten av trafikken din kommer fortsatt fra søkemotorer og lenker i sosiale medier. Hvis mobilnettstedet ditt er tregt, forsvinner de besøkende før de i det hele tatt ser lenken til appen din.
2. Er Dynamic Serving bedre enn responsivt design? I praksis er svaret ofte en hybrid. HTML og CSS forblir responsive og identiske for alle enheter, mens bildefiler, JavaScript og funksjoner som ikke er kritiske, tilpasses enheten og tilkoblingen.
3. Hva er LCP-målet for mobil i 2026? Terskelen for «bra» er 2,5 s ved 75. persentil av sidelastinger på mobil. Sikt under den med nok margin til at en kampanjeuke med mer trafikk ikke skyver siden over.

#Oppsummering

Google har gjennomsøkt og indeksert nettet som en smarttelefon siden migreringen ble fullført i 2023 og 2024. Arbeid med mobilytelse i WordPress handler nå om noen få målbare ting: det samme innholdet på alle enheter, et LCP-bilde som nettleseren finner i HTML-en, korte oppgaver rundt hvert trykk, reservert plass til alt som lastes sent, og sider som bfcache kan beholde. Mål dem i CrUX for de mobile besøkende, sjekk dem med Lighthouse på en strupet profil, og rett opp hvert måltall i Core Web Vitals i den rekkefølgen. For INP spesielt, se guiden til optimalisering av INP.

Hvis Core Web Vitals på mobil holder rangeringen din tilbake, kontakt WPPoland for en mobilrevisjon.