Mobielvriendelijke tester

Voer een URL in en de tester laadt deze op in een gesimuleerde telefoonweergave (standaard 375×812 pixels, afstemming op de schermafmetingen van een iPhone). De tester controleert veelvoorkomende problemen met mobiele leesbaarheid die eerder werden gemarkeerd door Googles eigen Mobile-Friendly Test voordat deze werd afgeschaft, en retourneert een lijst met fouten die u kunt corrigeren: ontbrekende viewport-meta-tag, tekst kleiner dan 12px, tikdoelgebieden kleiner dan 48×48px, horizontale scrollfunctie, gebruik van Flash of onondersteunde plugins, en inhoud die breder is dan de viewportafmeting.

Hoe de test verloopt

  1. 1

    Voer de URL in

    Volledige URL met protocol. Alleen openbare pagina's.

  2. 2

    De pagina wordt weergegeven in een weergave van telefoonafmetingen.

    Standaard 375×812; instelbaar.

  3. 3

    Geautomatiseerde controles worden uitgevoerd.

    Viewportmeta, tekstgrootte, afstand tussen tikdoelen, overspoeling, plugins.

  4. 4

    Voorbeeld en rapport

    Schermafbeelding van de weergegeven telefoontoestelling, samen met een lijst van specifieke problemen.

Wat de tester controleert

Configuratie van het weergavevenster

  • Bestaat er een <meta name="viewport" content="width=device-width, initial-scale=1">? Zonder deze component worden mobiele browsers weergegeven alsof het telefoon scherm dezelfde breedte heeft als een bureaublad, waardoor de weergave kleiner wordt en kleine teksten verschijnen.

Tekstgrootte

Alle weergegeven tekst met een lettergrootte van minder dan 12 px wordt gemarkeerd; deze is moeilijk te lezen op een telefoon zonder pinch-zoom. Veel stijlgidsen raden een minimum lettergrootte van 16 px aan. Zeer kleine ondertitels zijn acceptabel; tekst met een lettergrootte van 11 px daarentegen niet.

Grootte van het te tikken doelwit

  • Knoppen, links en formuliercontroles moeten minstens 48×48 px groot zijn (volgens de Google/W3C-richtlijnen voor mobiele toegankelijkheid). Kleinere doelen zijn moeilijk nauwkeurig te raken met de duim en worden gemarkeerd.

Afstand tussen de doelpunten van de tik

Doelwitten die dichter dan 8 px van aangrenzende doelwitten liggen, veroorzaken foutieve tikken en worden individueel gemarkeerd.

Horizontale scroll

– Content die breder is dan de weergavehoek, leidt tot horizontale swiping – een slechte mobiele gebruikerservaring. Dit wordt meestal veroorzaakt door een afbeelding zonder max-width: 100% of een tabel die niet kan worden aangepast aan het scherm formaat.

Onondersteunde plugins

Flash, Silverlight en ActiveX werken niet op telefoons. Oude websites gebruiken ze soms nog steeds.

Laden van lettertypen

  • Uiterst grote webfonten die de weergave voor enkele seconden blokkeren, worden gemarkeerd.

Waarom het nog steeds belangrijk is

Google stopte in december 2023 met zijn afzonderlijke Mobile-Friendly Test, maar mobiele geschiktheid blijft een directe rangschikkingsfactor op basis van Core Web Vitals en pagina-ervaringsmetriken. Met ‘mobile-first-indexing’ wordt je website gecrawld alsof die voor een smartphone is ontworpen; wat op mobiele apparaten niet goed werkt, verschijnt ook in de desktop-ranglijsten.

Typische correcties

  • Voeg een viewport-meta toe aan <head> en <meta name="viewport" content="width=device-width, initial-scale=1">.
  • Responsieve CSS met behulp van media queries: @media (max-width: 768px) { ... }
  • Flexbox en Grid in plaats van indelingen met vaste breedte.
  • Stel de afbeelding max-width: 100%; height: auto in zodat deze samen met het weergavevenster kleiner wordt.
  • Zorg dat tabellen op kleine schermen te scrollen zijn: gebruik <div style="overflow-x: auto"> voor het omvouwen van tekst.
  • Gebruik rem of em voor de tekstgrootte om zo een schaalverhouding volgens gebruikersvoorkeuren te realiseren.

Wat de tester niet opmerkt

Prestaties op echte hardware: Een budgettelefoon met Android en 3G-verbinding vertoont vertragingen die deze test niet simuleert. Gebruik Lighthouse voor een nauwkeurige beoordeling van de prestaties.

  • Touchinteracties: uitklaplijsten die alleen werken bij hoveren en die niet meer functioneren bij aanraking, moeten handmatig worden getest op een echt apparaat. – Toegankelijkheid die verder gaat dan alleen het formaat van mobiele schermen: contrast, ondersteuning voor schermlezers en toetsenbordnavigatie – gebruik daarvoor speciale toegankelijkheidsinstrumenten.
  • JavaScript-fouten op mobiele browsers. Safari op iOS gedraagt zich soms anders dan andere versies van WebKit.

Veelgestelde vragen

Soortgelijke controles, maar verschillende implementatie. Google heeft zijn openbare hulpmiddel eind 2023 stopgezet. Deze tester voert dezelfde reeks klassieke controles uit als die Google gebruikte, op de versie van de pagina die wordt geladen door een headless-browser.

Ja – Google gebruikt sinds 2020 een mobiele eerste-prioriteitstrategie, waardoor de weergave op mobiele apparaten de belangrijkste versie is voor de zoekrangschikking. Problemen met mobiele weergave hebben negatieve gevolgen voor de rangschikking, zelfs bij zoekopdrachten op desktopcomputers.

Nee. De tester haalt alleen URL’s op die openbaar toegankelijk zijn. Voor beveiligde testomgevingen kunt u de test lokaal uitvoeren met de apparaatemulatie-modus van Chrome DevTools.

De standaardresolutie is 375×812 (iPhone 12/13/14). Deze kan worden ingesteld op 390×844 (iPhone 14 Pro), 360×640 (standaardresolutie van Android-toestellen) of 412×915 (Pixel 7).

Meestal duurt het 5 tot 15 seconden, afhankelijk van de omvang van de pagina. Zware pagina’s met veel tekst zijn langer te laden; de tester wacht op het laden van de pagina en een korte pauze voordat hij de gegevens registreert.

Gerelateerde tools

Tool beschikbaar in andere talen