Mobile Page Speed: What Actually Matters and How to Fix It

Mobile page speed questions come up in almost every project we take on. The confusion is understandable — there are competing tools, scores that change every time you run them, and metrics Google keeps renaming. Here's a plain-English breakdown of what matters, what doesn't, and where to start.

Three reasons. Mobile scores are harder to earn, because phones have slower connections and less processing power than a desktop. Most local searches happen on a phone. And Google uses mobile-first indexing, meaning it evaluates the mobile version of your site to determine your rankings — even for searches made on a desktop.

That last point catches people off guard. A site that performs beautifully on a desktop and poorly on a phone is scored on the phone performance.

Page speed" is a vague term. Core Web Vitals are the specific metrics Google actually measures:

• Largest Contentful Paint (LCP): How fast the biggest element on the page — usually a hero image or headline block — finishes loading. Google's benchmark for good is 2.5 seconds or less.
• Interaction to Next Paint (INP): How quickly the page responds when someone taps or clicks. This replaced First Input Delay in 2024 and is stricter, which is why many sites that passed before now fail.
• Cumulative Layout Shift (CLS): Whether things jump around while the page loads. If a button moves as an ad or font finishes loading, that's a layout shift.

Passing all three is what "good page experience" means in Google's terms. You can read Google's own documentation on Core Web Vitals for the technical detail.

There isn't one best tool — they measure different things, and knowing which is which saves a lot of confusion.

• Chrome User Experience Report (CrUX): Real performance data from actual Chrome users visiting your site. This is what Google uses for ranking, and it's the most meaningful.
• PageSpeed Insights and Lighthouse: The same tool, run two different ways — Lighthouse locally, PageSpeed Insights on a server. Both simulate a device and connection rather than measuring real visits.

Simulated tests are useful for finding problems. Real user data tells you whether the problems actually affect anyone.

This one frustrates everybody. Run the same test three times and get three different numbers. That's normal — simulated tests are affected by your internet speed, available CPU at that moment, and server load. Nothing about your site changed between runs.

How we handle it: after any performance work, wait 20 to 30 minutes for caching to settle, then run the test three times and take the middle result. A single test immediately after a change tells you almost nothing.

In practice, most mobile speed problems trace back to the same handful of causes:

• Oversized images: The single most common culprit. Converting to WebP and sizing images to their display dimensions often fixes LCP by itself.
• Above-the-fold priority: The content visible on load should load first. Everything below can wait.
• Lazy loading: Images further down the page shouldn't block the initial render.
• Font loading: Fonts that swap in late cause layout shift and hurt CLS.
• Third-party scripts: Chat widgets, tracking pixels, and embedded players are frequently the heaviest things on a page.

This is the work we do in a website performance engagement — audit first, then fix in priority order, then verify with before-and-after

Platform choice sets your starting point. We build exclusively on Duda partly because performance work is built in at the platform level — above-the-fold prioritization, image optimization, lazy loading, and font handling are handled by the platform rather than bolted on with plugins.

As Russ Jeffery, Duda's Director of Platform Strategy, has explained, the platform's performance work covers image optimization, lazy loading, server optimization, and font optimization. His full interview on mobile page speed is worth reading if you want the platform-level detail.

A Lighthouse score above 70 is generally considered good, but the score itself matters less than passing Core Web Vitals — LCP under 2.5 seconds, plus acceptable INP and CLS. Those are the metrics Google actually uses.

Not really. Core Web Vitals include the metrics that define load speed, so a genuinely slow site won't pass them. If your Vitals are green, your mobile speed is in good shape.

Simulated tests reflect changes almost immediately, though caching and propagation can delay it. Real-user data in Search Console lags by weeks, since it's based on a rolling window of actual visits.

Yes. We start with a free AI website audit to identify what's slowing the site down, then either optimize it in place or rebuild it on Duda if the underlying structure is the problem.

Speed problems are usually invisible until you measure them. An audit gives you the real numbers — load speed, mobile performance, and what's causing the delays.