Mobile Friendly Test

What is a mobile friendly test and what does this tool measure?

A mobile friendly test checks whether a web page is easy to read and use on a phone. This tool opens a single address with Lighthouse on Google PageSpeed Insights, and emulates a mid-range phone on a slow mobile network. Then it sums up the result in one verdict. The verdict rests on three core checks:

• Viewport tag: does the page open at phone width, or as a shrunken desktop layout?
• Font size: can visitors read the text without zooming?
• Tap targets: can visitors hit buttons and links comfortably with a finger?

On top of that, one screen shows the zoom setting and the horizontal scroll risk. It also shows a mobile screenshot, a loading filmstrip, four Lighthouse scores and Core Web Vitals. I run this test in the first week of every SEO consulting project. That is because mobile problems rarely show up on a desktop screen, while most customers open the site on a phone.

Google retired its mobile friendly test: what should you use now?

Google announced the decision in April 2023. It shut down the Mobile-Friendly Test, its API and the Search Console Mobile Usability report on December 1, 2023. The reasoning was simple: since the tool first launched, far more thorough resources for evaluating mobile usability had appeared. Google therefore pointed site owners to Lighthouse from Chrome.

This tool fills that gap. You can also run Lighthouse on your own computer from Chrome DevTools; however, the result then depends on your machine and your network. PageSpeed Insights runs the test on Google's servers with a standard mobile profile, and it also adds real-user data when that exists. I explain how to read a Lighthouse report step by step in my article on the Google Lighthouse performance test.

One detail matters here: Lighthouse 13, released in October 2025, dropped the old font size audit. It also turned the viewport audit into a new insight audit. That is why the tool also reads the viewport tag from our own server. If no font size audit comes back, the row shows up as a note that stays out of the verdict.

Does being mobile friendly affect Google rankings?

Indirectly, but strongly. Since July 5, 2024, Google crawls every site with its smartphone crawler and indexes the mobile version of each page. So text, headings or structured data that are missing on mobile may not exist for Google either. Content that does not load on a mobile device at all cannot make it into the index.

On the other hand, Google states plainly in its page experience documentation that Core Web Vitals are part of its ranking systems. The same page also says that good scores do not guarantee top positions. The most relevant content can still rank even when its page experience is weak. My reading from the field: mobile usability and speed remove obstacles in front of good content; they do not lift weak content on their own.

I cover how speed affects rankings and conversions, with examples, in how site speed affects SEO.

Why does the viewport tag matter so much?

The viewport tag tells the browser how wide to lay out the page. Without it, some mobile browsers render the page in a virtual desktop width of 980 pixels and then shrink it to fit the screen. The result is a tiny desktop view that nobody can read without zooming. You spot this right away in the tool's screenshot.

The correct tag is a single line: <meta name="viewport" content="width=device-width, initial-scale=1">. Still, I keep seeing three mistakes in that one line:

• Fixed width: a value such as width=980 forces the phone into a desktop width.
• Zoom lock: user-scalable=no, or a maximum-scale below 2, stops people with low vision from enlarging text; WCAG asks for at least 2x scaling.
• Duplicate tags: when a theme and a plugin each print a tag, the browser applies the last one, so your setting can quietly lose.

To set the tag together with your title and description tags, use the meta tag generator.

What sizes are right for tap targets and font size?

For tap targets, the current yardstick is WCAG 2.2 criterion 2.5.8. Each target should be at least 24 × 24 CSS pixels. Otherwise, small targets need enough space that 24 pixel circles around them do not overlap. The Lighthouse target-size audit checks exactly this rule. For important buttons, the 44 × 44 pixels of criterion 2.5.5 is a more comfortable goal. The old Lighthouse tap-targets audit used 48 × 48 pixels.

In practice, these are the small targets I catch most often: crowded footer links, social media icons, carousel dots and links placed side by side inside text. Moreover, the fix rarely breaks the design; adding padding enlarges the tappable area while the visible icon stays the same.

For font size, Lighthouse used to expect at least 60 percent of the text to be 12 pixels or larger. Lighthouse 13 removed that audit, so there is no automatic score anymore. I recommend never going below 16 pixels for body text. I also judge it from the screenshot: if you cannot read the text without zooming, neither can your visitor.

How should you read Core Web Vitals results?

The tool shows two kinds of data and always labels which one you are looking at. The Real users tab comes from the Chrome User Experience Report (CrUX). It holds data from real Chrome users who opened your page over the last 28 days, and PageSpeed Insights reports it at the 75th percentile. If the page lacks enough data, PageSpeed Insights falls back to the whole origin; if that also falls short, no real-user data appears.

The Lab tab is a single Lighthouse run. Because nobody actually taps anything in the lab, the test cannot measure INP; instead, the tool shows Total Blocking Time (TBT). The thresholds:

• LCP: 2.5 seconds or less is good, over 4 seconds is poor.
• INP: 200 ms or less is good, over 500 ms is poor.
• CLS: 0.1 or less is good, over 0.25 is poor.
• TBT: 200 ms or less is good, over 600 ms is poor.

When the two disagree, trust the real-user data, because that is the experience Google evaluates. The lab, in turn, is ideal for finding the cause of a problem and trying a fix right away. I gathered all user experience signals in my article on SEO and UX page experience factors.

What should you fix first after a mobile friendly test?

I turn a test result into a to-do list in this order.

1. Viewport: if the tag is missing or has a fixed width, fix it first; every other measurement depends on it.
2. Horizontal overflow: if the screenshot shows an image, table or iframe spilling to the right, limit its width with a percentage.
3. Tap targets: add padding to the listed elements or space them further apart.
4. LCP: compress the largest image and serve it at the right size; the image resizer is enough for that.
5. CLS and INP: give images dimensions and defer heavy third-party scripts.

Problems that come from the theme keep coming back after every patch. In that case, moving to a mobile-first structure is cheaper in the long run; I explain the difference in what is mobile first design. If you need a build from scratch, I make a passing mobile test a delivery condition in every web design project.