The mobile Speed Update: what actually moves the score

The announcement was short. Mobile page speed becomes a ranking signal from July 2018, it applies the same standard to all pages regardless of technology, and it uses a mix of signals rather than a single metric. Google has not said what counts as slow, has not confirmed which metrics it uses, and has said that intent still matters more: a slow page with the best answer can still rank.

This arrives alongside mobile-first indexing, which started rolling out to sites in March. Together they mean the mobile version of your site is now the one Google evaluates for both content and speed. If your desktop site is fast and your mobile site is a stripped-down afterthought, the afterthought is what counts.

Three tools cover almost everything.

Lighthouse, built into the Chrome DevTools Audits panel since Chrome 60 and now at version 3, runs a page on a simulated mid-range phone over a throttled connection and produces a Performance score from 0 to 100 with the metrics behind it: First Contentful Paint, First Meaningful Paint, Speed Index, Time to Interactive and First CPU Idle. These are lab numbers. They are reproducible, which makes them ideal for testing a change.

PageSpeed Insights now shows Chrome User Experience Report data (field data from real Chrome users) for sites with enough traffic, alongside its optimization suggestions. If your page shows a field distribution for First Contentful Paint and DOM Content Loaded, that is the closest thing you have to what Google sees.

WebPageTest gives you a filmstrip and a waterfall from a real device in a real location, with a Moto G4 on 3G as a sensible default profile. It is the best tool for understanding why a page is slow rather than how slow it is.

Run all three on your five most important mobile pages (home, top category or service page, top product or landing page, a blog post, the contact or checkout page) and record the baseline. Typical numbers for a small-business site that has had no speed work this year: a Lighthouse Performance score of 20 to 45 on mobile, First Contentful Paint of 3 to 5 seconds, Time to Interactive of 8 to 15 seconds, page weight of 2.5 to 5 MB.

In order of typical impact for a business site, not in order of how often they are talked about.

1. Images

On most sites images are 60 to 80 percent of page weight, and the fix is mechanical.

• Resize to the largest size actually displayed. A 4,000-pixel-wide hero shown at 400 pixels on a phone is the single most common problem.
• Serve responsive images with srcset and sizes so phones get small files and desktops get large ones.
• Compress. JPEG at quality 75 to 82 is indistinguishable from 100 to most people and a third of the size. Tools like ImageOptim, Squoosh (new from the Chrome team this year) or an image CDN such as Cloudinary or imgix do this automatically.
• Consider WebP for Chrome and Android users, served with a <picture> fallback since Safari does not support it. Savings run 25 to 35 percent over a well-compressed JPEG.
• Lazy-load anything below the fold with an IntersectionObserver-based script. Native browser support for lazy loading is not here yet.

Image work alone often takes a page from a 30 to a 55 or 60.

2. Third-party scripts

The tag manager has made it too easy to add things. Audit every script loading on a mobile page: analytics, pixels, chat widgets, heatmaps, A/B testing tools, review badges, social embeds, fonts. A typical small-business site runs 15 to 30 third-party requests, and a chat widget or an A/B testing snippet can add 1 to 3 seconds of main-thread work on a mid-range phone.

Decision rule: if nobody has looked at the data from a tool in ninety days, remove it. Load what remains with async or defer. Move anything not needed for the first screen to fire after the page is interactive.

3. Server response and hosting

Time to First Byte over 600 ms on a mobile connection is a hosting or caching problem. Fixes, in order: page caching (a plugin on WordPress, built-in on hosted platforms), a CDN such as Cloudflare or Fastly in front of the origin, HTTP/2 (which most CDNs and modern hosts now enable by default), and, if TTFB remains slow, a better host. Moving from a $5-a-month shared plan to managed hosting at $30 to $100 a month is often the cheapest second-best improvement after images.

4. Render-blocking CSS and JavaScript

Inline the CSS needed for the first screen, defer the rest. Remove unused CSS: the Coverage tab in Chrome DevTools shows how much of each file is never used, and on theme-heavy sites it is commonly 70 to 90 percent. Minify and combine where HTTP/2 is not available.

5. Fonts

Each web font family and weight is a request, and by default text is invisible until it arrives. Limit to two families and three or four weights, self-host or preconnect to the font host, and set font-display: swap so text shows immediately.

Chasing 100 on a business site with analytics, a pixel and a chat tool is a poor use of money. A sensible target for this year: Lighthouse mobile Performance of 60 or above, First Contentful Paint under 2 seconds, Time to Interactive under 5 seconds on the throttled profile, and page weight under 1.5 MB on key pages. Google's own guidance has long pointed to interactive under 5 seconds on a mid-range device on 3G.

The number that matters more is in your analytics. Compare mobile bounce rate and mobile conversion rate for the four weeks before and after the speed work, segmented by landing page. A one-second improvement in load time on a retail site commonly moves mobile conversion by 5 to 10 percent, which usually pays for the work several times over before rankings enter into it.

Optimizing the desktop site. Lighthouse defaults to a mobile profile for a reason. Test on the throttled mobile setting and on a real mid-range Android phone if you can.

Treating the score as the goal. The score is a proxy. If your filmstrip shows usable content at 1.5 seconds and the score is 55 because of a deferred chat widget, you are fine.

Installing a speed plugin and stopping. Caching and minification plugins help, but they do not resize your images or remove your unused scripts.

Letting it drift. Speed decays as people add images, apps and tags. Put Lighthouse in your monthly checklist, or automate it with the Lighthouse CLI in your build.

Forgetting the checkout and forms. The most valuable pages are often the heaviest, loaded with payment scripts and validation libraries. Audit them separately.

Speed work sits inside a connected plan across brand, growth, web and technology, because a fast page that nobody reaches, or that converts poorly once it loads, has not solved anything. Discover is the baseline: Lighthouse and WebPageTest on key pages, a third-party script inventory, hosting and CDN review, and the mobile conversion and bounce data from analytics. Plan ranks fixes by gain per day of effort and sets a target per page type rather than a single site-wide number. Build is the image pipeline, script cleanup, caching and CDN configuration, critical CSS and, where the platform cannot get there, a template or theme rebuild. Improve is monthly monitoring, a speed budget written into the content and tagging process, and a review of how mobile conversion moved.

The infrastructure engagement is the representative pattern. A company's mobile site had grown heavy over several years of additions: oversized imagery, a dozen marketing tags and shared hosting that struggled under campaign traffic. After a baseline audit, the work moved in stages: an automated image pipeline with responsive sizes, a tag audit that removed unused tools and deferred the rest, a CDN with HTTP/2 and full-page caching, and critical CSS for the main templates. Mobile load times fell by more than half, Lighthouse scores moved from the low thirties to the sixties, and the measurable result was a clear lift in mobile conversion and a far more stable site during paid campaigns.