Free · Fast · Privacy-first

Mobile Website Speed Test

Google ranks your website primarily based on its mobile performance under the mobile-first indexing policy adopted years ago.

⚡

Mobile device emulation (4G, typical Android CPU)

🔒

Mobile Core Web Vitals scoring

✨

Mobile-specific recommendations

⚡

No sign-up required

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this Website Speed Test to your website

Drop the Website Speed Test into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/web-tools/website-speed-test?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Website Speed Test by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/web-tools/website-speed-test?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Website Speed Test by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

Mobile Website Speed: Why It Matters More Than Desktop Performance

Google switched to mobile-first indexing in 2019, meaning it primarily uses the mobile version of your website to determine search rankings rather than the desktop equivalent. This makes mobile performance the definitive speed metric for SEO purposes, full stop. The gap between mobile and desktop performance is significant for most sites: mobile devices have processors three to ten times slower than modern laptops, cellular connections have higher latency than broadband even on 4G, and mobile browsers must render pages at smaller viewport sizes while also handling touch events that desktop pointers do not require. The median mobile web page achieves an LCP of approximately 3.5 to 4 seconds, well above Google's 2.5 second good threshold. This means the majority of websites are failing the mobile performance threshold that Google uses as an explicit ranking signal.

Mobile speed optimisation targets a different set of bottlenecks than desktop optimisation, which is why a site that scores 95 on desktop can score 50 on mobile despite serving the same code. The single largest impact fix for mobile is usually JavaScript execution time. JavaScript that runs in 50 milliseconds on a modern desktop can take 300 to 500 milliseconds on a mid-tier Android phone, which remains the most common mobile device globally. Total Blocking Time (TBT), which measures the sum of all blocking tasks over 50 milliseconds during page load, is the Lighthouse metric most predictive of poor mobile interactivity. Reducing JavaScript bundle size through code splitting and tree shaking, deferring non-critical scripts, and eliminating unused third-party scripts consistently deliver the largest mobile TBT improvements available.

Responsive image implementation is the second highest-impact mobile optimisation. Serving desktop-resolution images at 1200 pixels or more to mobile devices displaying at 375 pixels wastes bandwidth and adds unnecessary download time without any visual benefit. Use the HTML srcset and sizes attributes to serve appropriately sized images for each device automatically. Convert images to WebP format, which is typically 30 percent smaller than JPEG at equivalent visual quality. Combine srcset with lazy loading for below-fold images to defer downloads until the user actually scrolls toward them. These responsive image techniques typically reduce mobile page weight by 40 to 60 percent on image-heavy pages, with proportional improvements in LCP and total load time.

A third mobile-specific consideration that frequently surprises teams is the cost of web fonts on slower devices and networks. Custom fonts often require multiple file downloads, each potentially several hundred kilobytes, and they block text rendering until they finish loading unless font-display is configured correctly. On mobile networks the cumulative font download cost can add 1 to 2 seconds to LCP if the font is involved in rendering the largest contentful element. Subset your fonts to include only the characters and weights you actually use, set font-display: swap so fallback fonts render immediately rather than leaving text invisible, and preload your most critical font with rel="preload" to start the download as early as possible. Many sites that struggle with mobile LCP have a font in the critical rendering path that nobody has thought to optimise.

Google: Mobile-First Indexing Best Practices web.dev: Serve Images in Modern Formats

How to use this tool

💡

Test your URL under mobile conditions, Google's standard for mobile-first indexing.

How It Works

Step-by-step guide to mobile website speed test:

1
Select mobile test mode
Choose mobile in the test settings to simulate a mid-range Android device on a throttled 4G connection. This is Google's standard configuration for Core Web Vitals measurement and aligns with how the search crawler evaluates pages for ranking purposes. Skipping the mobile mode and only running desktop tests will produce flattering scores that do not reflect how Google actually sees your site.
2
Run the test
Enter your URL and run the test. Allow extra time compared to a desktop test because mobile simulation involves additional CPU and network throttling that extends the page load duration. A typical mobile test takes 30 to 60 seconds to complete. Do not interrupt the run because partial results are not saved and you will need to start the test over from scratch.
3
Review mobile-specific metrics
Check LCP under mobile conditions with a target under 2.5 seconds, TBT with a target under 300 milliseconds, and CLS with a target under 0.1. These three metrics together represent the most important mobile-specific performance indicators. Pay particular attention to TBT because mobile CPUs amplify the cost of every JavaScript task and small improvements often deliver large mobile score gains.
4
Focus on mobile-specific improvements
Prioritise responsive images through srcset, JavaScript bundle reduction, eliminating render-blocking resources, and deferring third-party scripts that do not need to execute during initial load. These optimisations have the highest impact on mobile performance specifically because they target the bottlenecks that mobile hardware and networks amplify most severely compared with desktop environments.

Real-world examples

Common situations where this approach makes a real difference:

Mobile SEO audit

An SEO specialist runs mobile speed tests on a client's top 10 landing pages before presenting strategic recommendations. Seven of ten pages score under 50 on mobile due to a combination of large unoptimised image files and render-blocking scripts loading in the document head. The data provides a clear high-priority action list ranked by traffic impact, transforming what would otherwise be a vague conversation about performance into a specific, defensible plan with realistic expected ranking benefits the client can review with engineering.

AMP migration decision

A news publisher considering an AMP implementation tests their current mobile performance to inform the decision. Scores above 75 across their top article templates suggest that mobile speed is not a critical bottleneck and that AMP's complexity and design restrictions may not justify the investment. They choose instead to invest the development effort in optimising their existing templates further, achieving comparable mobile speed without sacrificing the design flexibility that AMP's strict format would require them to give up across their entire content library.

Developer mobile performance regression testing

A developer runs mobile speed tests after each sprint to catch performance regressions before they reach production where they would affect real users and search rankings. A score drop from 82 to 64 in a single sprint immediately triggers investigation of what changed during the iteration. The culprit turns out to be a new image carousel component loading all images eagerly rather than lazily. The fix is small, the regression never ships, and the team avoids the embarrassment of a public performance drop that would have required a post-mortem.

When to use this guide

Use this for any website you want to rank in Google, especially for mobile-heavy audiences. Mobile speed is the primary factor in Google's Page Experience ranking signal.

Pro tips

Get better results with these expert suggestions:

Simulate real mobile conditions when testing

Testing on a fast home or office internet connection understates real mobile load times by three to five times the actual experience your users encounter. Use Google PageSpeed Insights' mobile test, which simulates a mid-tier Android device on a throttled 4G connection with 150ms latency. This is the condition closest to Google's own mobile-first indexing crawler and better represents your median mobile visitor than any test run on developer-class hardware over corporate broadband.

Minimise Total Blocking Time for mobile interactivity

Total Blocking Time (TBT) is the single most impactful Lighthouse metric for mobile performance, weighted at 30 percent of the composite score. It measures cumulative JavaScript execution that blocks the main thread during page load. Reduce TBT by splitting large JavaScript bundles, removing unused code through tree shaking, and deferring analytics and third-party scripts to load after the page becomes interactive. A TBT reduction from 500 to 100 milliseconds often adds 15 to 25 points to the mobile Lighthouse score on its own.

Implement responsive images with srcset

Never serve desktop-resolution images to mobile devices unless you genuinely have no choice. Use the HTML srcset attribute together with sizes to provide multiple image sizes and let the browser pick the appropriate one for the current viewport and pixel density. A mobile user viewing a 375 pixel wide hero image should receive an image around 750 pixels for retina rendering, not a 1200 pixel desktop version that wastes bandwidth. This single technique can reduce mobile page weight by 40 to 60 percent on image-heavy pages.

Check your AMP pages if you use them

If your site uses AMP (Accelerated Mobile Pages), AMP pages are served from Google's AMP cache at near-zero latency for mobile search results, which can provide a measurable speed advantage for news and editorial content. However, AMP pages have strict implementation requirements that limit design and functionality. Use Google's AMP Validator to confirm your AMP pages are implemented correctly. If validation fails, Google falls back to your canonical mobile page and you lose the AMP cache benefit entirely without realising it.

Mobile scores are always lower than desktop, this is normal

Mobile tests simulate slower CPUs and connections. A score of 70–80 on mobile may represent genuinely good performance. Aim for 80+ on mobile; achieving 90+ on mobile usually means your desktop score is excellent.

Responsive images are the most impactful mobile optimisation

Serving oversized desktop images to mobile devices is the single biggest waste of mobile bandwidth. Implement srcset or next-gen image formats (WebP, AVIF) to serve correctly-sized images for each screen.

Reduce JavaScript for mobile users

JavaScript parsing is far slower on mobile CPUs. Reducing JavaScript bundle size and deferring non-critical scripts has a disproportionate positive impact on mobile performance versus desktop.

FAQ

Frequently asked questions

Google uses mobile-first indexing across nearly all sites, meaning it primarily uses the mobile version of your site to determine search rankings rather than the desktop version. Your mobile performance score directly influences your position in search results regardless of whether your visitors arrive from mobile or desktop devices. Additionally, mobile devices account for over 60 percent of global web traffic, making mobile experience critical for user retention as well as rankings. Investing in mobile performance is effectively investing in both ranking signals and user experience for the majority of your visitors at the same time, while desktop investment is increasingly a secondary priority.

Google considers a Lighthouse performance score of 90 or higher as Good, 50 to 89 as Needs Improvement, and 0 to 49 as Poor. For mobile specifically, a score of 80 or higher is a realistic and competitive target for most production sites. Very image-heavy or JavaScript-dependent sites may find 70 to 80 is achievable before diminishing returns set in and each additional point requires disproportionate engineering effort. The most important mobile metrics to optimise are LCP under 2.5 seconds and INP under 200 milliseconds, since these are explicit Google ranking thresholds and feed directly into the Page Experience signal.

Google PageSpeed Insights, and Lighthouse running in default mode, simulates a Moto G Power class device on a throttled 4G connection with approximately 150 milliseconds of latency and roughly 1.6 megabits per second of download bandwidth. This represents a mid-tier mobile experience, better than 3G but considerably slower than a typical home broadband connection. The configuration is intended to reflect a realistic global mobile user rather than a best-case scenario. Optimising to this profile means your site will feel acceptably fast even for users on slower or congested cellular connections rather than only for those on premium networks.

The highest-impact mobile optimisations in rough order of return on effort: first, convert images to WebP and implement responsive srcset to send appropriately sized images for each device. Second, defer non-critical JavaScript particularly third-party analytics, chat, and advertising scripts. Third, enable server-side caching to improve TTFB which directly improves every downstream metric. Fourth, remove unused CSS and JavaScript identified through the Chrome DevTools Coverage tab. Fifth, use a CDN to reduce latency for geographically distributed users. These five fixes typically achieve the largest mobile performance gains and can be implemented incrementally rather than requiring a single large project.

In practice, mobile performance is always worse than desktop due to inherent hardware and network constraints that no amount of optimisation can fully overcome. However, the gap should be manageable rather than yawning. If your desktop Lighthouse score is 90 and mobile is 40, there is an abnormally large gap indicating mobile-specific issues like render-blocking scripts loading on mobile only, non-responsive images, or heavy JavaScript that struggles on weaker CPUs. A healthy ratio is desktop score no more than 25 points above mobile. Larger gaps usually point to specific fixable issues rather than universal hardware constraints.

3G connections have approximately 400 milliseconds of latency and around 1 megabit per second of download bandwidth. 4G (LTE) has approximately 50 to 150 milliseconds of latency and 5 to 20 megabits per second of download. The impact on page loading is substantial: a page loading in 3 seconds on 4G can take 8 to 12 seconds on 3G under realistic conditions. For sites targeting developing markets or rural regions where 3G remains common, optimising for 3G conditions is essential rather than optional. Use a real device or Chrome DevTools 3G throttling to test worst-case scenarios for your audience profile.

AMP (Accelerated Mobile Pages) can significantly improve mobile speed because Google serves AMP pages from its own AMP cache at near-zero latency when users click through from mobile search results. The cache effectively guarantees a fast first paint regardless of your origin server speed. However, AMP has strict technical requirements that significantly limit design and functionality flexibility, and the project itself has been deprioritised by Google in recent years. Most modern sites achieve equivalent or better real-world performance through standard web optimisation techniques such as WebP images, code splitting, and CDN deployment without taking on AMP's restrictions.

You do not need a physical mobile device to run accurate mobile speed tests because the major testing tools simulate mobile hardware and network conditions in software. PageSpeed Insights, WebPageTest, Lighthouse in Chrome DevTools, and FixTools Website Speed Test all support mobile emulation that closely matches real device behaviour for measurement purposes. That said, validating findings on a real mid-range Android phone is valuable because emulation cannot fully capture subjective feel, touch responsiveness, or device-specific browser quirks that only show up on real hardware. Keep one cheap test device around for spot checks even if your primary measurement uses emulation.

Real-world mobile experience often feels worse than synthetic test scores for several reasons. Tests run from controlled server locations may not reflect the latency your distant users actually experience. Test environments use a fixed network profile while real users encounter variable signal strength, congested cell towers, and intermittent throughput throttling. Tests do not capture interaction delays that appear after initial page load when users scroll, tap, or trigger JavaScript-heavy features. To bridge the gap, supplement synthetic tests with field data from CrUX or RUM tools that report what real users actually experience rather than what a controlled simulation predicts.