Je website op mobiel testen

Om te controleren of je website mobiel werkt, combineer je een prestatierapport met een praktische test van de taak van de bezoeker. Een snelle pagina kan een onbereikbare verzendknop hebben. Een responsive layout kan nog steeds formuliergegevens verliezen.

Google heeft de Mobielvriendelijke test en de API in december 2023 stopgezet. PageSpeed Insights, Lighthouse, browseremulatie en een echte telefoon controleren verschillende onderdelen. Geen daarvan bewijst op zichzelf dat een website bruikbaar, toegankelijk of klaar voor goede zoekposities is.

Kies belangrijke pagina’s en handelingen

Begin met de homepage, een belangrijke product- of dienstenpagina en een artikel. Neem de echte contact-, boekings- of aankooproute mee, ook als die naar een ander domein leidt. Test relevante talen en toestanden: een eerste bezoek met toestemmingsbanner, een herhaalbezoek, een geopend menu en een formulier met een foutmelding.

Onze gratis mobiele checker kan als eerste controle dienen. Hij onderzoekt opgehaalde HTML en responsinformatie op aanwijzingen, zoals een ontbrekende viewporttag, vaste inlinebreedtes en heel kleine tekst met inlineopmaak. Hij rendert de pagina niet, voert geen JavaScript uit en berekent geen layout op basis van externe stylesheets. De HTML-grootte is niet het totale downloadvolume; de ophaaltijd is geen laadtijd op een echte telefoon. Controleer meldingen in een browser.

Lees de twee soorten PageSpeed-resultaten

Open PageSpeed Insights, voer de openbare URL in en selecteer Mobiel.

De veldgegevens komen uit het Chrome UX Report en betreffen de voorafgaande 28 dagen. Controleer of de kop ‘Deze URL’ of ‘Oorsprong’ vermeldt. Bij onvoldoende URL-gegevens kan PageSpeed terugvallen op de oorsprong: pagina’s met hetzelfde protocol, dezelfde hostnaam en poort. Een geslaagde beoordeling van de oorsprong bewijst niet dat de specifieke pagina is geslaagd. Zijn er op beide niveaus te weinig gegevens, dan is een ontbrekende beoordeling geen onvoldoende.

Het labgedeelte is een nieuwe Lighthouse-test onder gesimuleerde omstandigheden. Gebruik die om een trage bron of blokkerend script te onderzoeken. De prestatiescore staat los van de veldbeoordeling. Eén navigatietest meet niet de INP van je bezoekers. Google legt deze verschillen uit.

Bekijk het opgeslagen mobiele rapport van 4 augustus 2026 op volledige grootte (Oorsprong geselecteerd; Core Web Vitals geslaagd)

Dit opgeslagen voorbeeld toont veldgegevens van de oorsprong: LCP 2,4 seconden, INP 112 milliseconden en CLS 0. Het bevat geen Lighthouse-prestatiescore. Het laat zien hoe je het bereik van een rapport leest; het is geen actuele meting van onze homepage.

Wat de Core Web Vitals-grenzen betekenen

De indeling gebruikt het 75e percentiel van de betreffende veldmetingen, niet het gemiddelde:

Voor een volledige geslaagde beoordeling moeten alle drie goed zijn. Bij onvoldoende INP-gegevens kan PageSpeed toch een geslaagde beoordeling geven als LCP en CLS goed zijn. Onvoldoende LCP- of CLS-gegevens verhinderen een beoordeling. Deze gedocumenteerde PageSpeed-regel vervangt geen interactietests.

Vergelijk Search Console op hetzelfde niveau

Open Core Web Vitals en het mobiele rapport in Search Console. Bekijk de getroffen groep, de slechtste maatstaf en de voorbeeld-URL’s. Google groepeert pagina’s met vergelijkbare ervaringen. Zo’n groep valt niet noodzakelijk samen met je paginasjablonen. Reproduceer het probleem voordat je een gedeeld onderdeel als oorzaak aanwijst.

PageSpeed en Search Console kunnen verschillen als je uitsluitend veldgegevens vergelijkt. Controleer URL, oorsprong of groep, apparaat, meetperiode en URL-verwerking. Search Console onderscheidt URL-parameters; PageSpeed-veldgegevens worden zonder die parameters samengevoegd. Niet ieder verschil is dus ‘lab tegenover echte gebruikers’. De rapportdocumentatie beschrijft deze verschillen.

Controleer een gepubliceerde oplossing meteen met dezelfde browserstappen en labinstellingen. Veldresultaten veranderen naarmate nieuwe bezoeken in het voortschrijdende tijdvak komen. ‘Tracking starten’ begint een validatie van 28 dagen; het dwingt geen crawl of herindexering af. De getoonde gegevens kunnen eerder veranderen, terwijl validatie nog steeds de meetperiode en voldoende gegevens nodig heeft.

Leg Lighthouse-instellingen vast

Open de pagina in Chrome en vervolgens DevTools. Kies Lighthouse en selecteer Mobiel voordat je de audit start. De lokale versie van Lighthouse kan ingelogde pagina’s testen die een openbare PageSpeed-aanvraag niet bereikt. De Lighthouse-documentatie beschrijft de mogelijkheden.

Bewaar rapport, datum, URL, Lighthouse-versie, apparaatprofiel, vertragingsinstellingen en geteste paginaversie. Houd die omstandigheden gelijk bij een vergelijking en herhaal een verrassend resultaat. Computer, browser, toestemmingstoestand en testconfiguratie kunnen de meting veranderen. Een processor handmatig vertragen in DevTools garandeert geen overeenkomst met PageSpeeds simulatie.

Automatiseer een labtest met de PageSpeed-API

Dit Bash-commando vraagt mobiele diagnostiek voor prestaties, toegankelijkheid en SEO op. Vervang de voorbeeld-URL door een openbare pagina:

curl --get \
  'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
  --data-urlencode 'url=https://example.com/' \
  --data-urlencode 'strategy=mobile' \
  --data-urlencode 'category=performance' \
  --data-urlencode 'category=accessibility' \
  --data-urlencode 'category=seo'

Gebruik onder Windows een Bash-terminal voor deze syntaxis over meerdere regels. De startgids beschrijft toegang en raadt een sleutel aan voor veelvuldige automatische aanvragen. Controleer het projectquotum voordat je series inplant. Een HTTP-fout, ook vanwege een quotum, betekent niet dat de geteste pagina is gezakt.

Lees binnen lighthouseResult de velden categories en audits; een categoriescore van 0.92 is 92 van 100. Bewaar fetchTime, lighthouseVersion, requestedUrl, finalUrl en configSettings, en handel runtimeError af voordat je het resultaat accepteert. Zie de responsreferentie. Voor doorlopende veldmetingen raadt Google de CrUX API of CrUX History API aan, omdat het CrUX-gegevens uit de PageSpeed-API wil verwijderen.

Test de taak in de browser en op een telefoon

Schakel de apparaatwerkbalk van DevTools in en begin met 360 × 800 en 390 × 844 CSS-pixels. Verander de breedte geleidelijk en test de liggende stand. De apparaatmodus is een benadering. Eindig op fysieke apparaten en browsers die jouw bezoekers gebruiken, waar relevant ook Safari op iPhone.

• Open en sluit navigatie, toestemmingsinstellingen en dialoogvensters. Vaste kopbalken en banners mogen tekst en knoppen niet bedekken.
• Lees lange koppen, tabellen en vertalingen. Test zoom en smalle weergave. Het reflowcriterium van de richtlijnen voor toegankelijke webinhoud (WCAG) gebruikt 320 CSS-pixels voor verticaal scrollende inhoud, gelijk aan een viewport van 1280 pixels bij 400% zoom. Echte tweedimensionale tabellen hebben een uitzondering: behoud leesbaarheid en bruikbaar scrollen in plaats van overloop te verbergen.
• Tik op naburige knoppen en gebruik waar ondersteund een toetsenbord. Het WCAG 2.2 AA-criterium voor doelgrootte gebruikt 24 × 24 CSS-pixels met afstands- en andere uitzonderingen. Grotere vlakken, bijvoorbeeld 48 × 48, kunnen prettiger zijn. Geen van beide afmetingen bewijst op zichzelf toegankelijkheidsconformiteit.
• Vul het formulier in met het schermtoetsenbord open. Controleer labels, focus, fouten, behouden invoer, verzending en bevestiging. Gebruik voor aankopen of boekingen een goedgekeurde testomgeving en controleer het bijbehorende ontvangstbewijs of record.
• Herhaal via een relevante mobiele verbinding. Bij traag laden of een mislukte aanvraag moet duidelijk zijn hoe iemand verder kan.

Een nuttige foutmelding is specifiek. Hypothetisch voorbeeld: ‘Op de boekingspagina bij 390 × 844 bedekken toetsenbord en toestemmingsbanner de verzendknop. De pagina scrolt, maar de knop blijft onbereikbaar.’ Voeg URL, browser, apparaat, toestand, stappen, screenshot, verwacht resultaat en verantwoordelijke toe. Een geblokkeerde boeking verdient aandacht, ook bij een groene prestatiescore.

Los de gemeten oorzaak op

Zoek bij trage LCP het werkelijke grootste element en de oorzaak van de vertraging. Is het een afbeelding, maak die dan vroeg vindbaar en laad die niet vertraagd. Gebruik preload alleen wanneer een bron eerder moet worden ontdekt, niet voor alle afbeeldingen en lettertypen. Googles LCP-gids legt dit verschil uit.

Leg een trage interactie vast en onderzoek blokkerend werk. Verminder onnodige scripts of splits lange taken, met behoud van vereiste functies en toestemming. Reserveer tegen layoutverschuivingen ruimte voor afbeeldingen, embeds en ingevoegde inhoud. De gidsen voor INP en CLS helpen bij deze verschillende problemen.

Test in WordPress of Shopify een thema- of appwijziging in een testomgeving met dezelfde inhoud en route. Meet het effect voordat je alle plugins de schuld geeft of herbouw voorstelt. Sommige oplossingen zitten in instellingen, andere vragen een wijziging aan een component. Onze websiteoptimalisatie helpt bij diagnose en uitvoering, met websiteontwikkeling wanneer code moet veranderen.

Houd indexering en bruikbaarheid apart

Google raadt responsive design aan voor mobile-first indexering, maar ondersteunt ook andere mobiele configuraties. Zorg dat Googlebot mobiele inhoud, afbeeldingen en metadata kan bereiken. Een bruikbare pagina kan nog steeds een indexeringsprobleem hebben dat apart SEO-onderzoek vraagt.

Core Web Vitals tellen mee in Googles rankingsystemen, maar goede scores garanderen geen hoge positie en een slechte score bewijst geen straf. Googles richtlijnen voor paginabeleving plaatsen ze naast de bredere waarde van een pagina.

Bewaar een praktisch verslag: gevonden probleem, gepubliceerde wijziging, succesvol herhaalde taak en nog openstaande veldvalidatie. Controleer de betrokken routes na wijzigingen aan thema, app, formulier of tags opnieuw. Een positieve beoordeling in een rapport en een bezoeker die de taak afrondt, zijn afzonderlijke controles.