Why is your website slow on mobile? A plain-English diagnosis

If your website is slow on mobile, the phone is usually revealing a problem that a fast laptop and office connection can hide. The delay may begin at the server, in an oversized image, or in code that keeps the phone busy after the page looks ready. The right fix depends on where the time goes—not on installing a generic speed plugin or chasing a perfect score.

A useful diagnosis asks when the main content appears, whether the page answers a tap, and whether anything moves while the visitor is trying to use it. Those questions map closely to Core Web Vitals and to what a customer actually experiences.

“Slow” is an experience, not one test score

A page can earn a respectable PageSpeed Insights score and still feel bad. The phone may show a blank screen before the headline appears. The page may look complete but ignore the first tap. A booking button may jump just as a visitor touches it. A product page may be quick for someone near the server and slow for a customer across the country.

PageSpeed Insights helps separate two kinds of evidence:

Field data describes experiences collected from real Chrome users over the previous 28 days. It reflects a mix of phones, networks and locations. A smaller or newer site may not have enough traffic for page-level field data, so the tool may show site-wide data or none at all.
Lab data is one simulated page load under controlled mobile conditions, produced by Lighthouse. It is useful for reproducing a problem and finding likely causes, but it is not a census of your customers.

Field data tells you whether real people have a recurring problem. Lab data helps a developer investigate why. The two can disagree without either being wrong. Google’s guidance on lab and field data recommends prioritizing field evidence when available and using lab tests for diagnosis and pre-launch checks.

The large 0–100 Performance score summarizes several lab measurements. It can change between runs, and a green score does not guarantee good real-user results. Neither that score nor a Core Web Vitals pass is the business outcome. A useful page and a completed enquiry matter more.

What the symptom is trying to tell you

What the user sees	Likely cause	Simple test	Likely owner
A blank or incomplete page for several seconds	Slow server response, redirects, cache miss or render-blocking files	Compare the “server response” and LCP diagnostics in PageSpeed Insights	Host or developer
The headline appears, but the main photo arrives much later	Oversized hero image, wrong dimensions, weak compression or late image discovery	Note the LCP element and “Improve image delivery” finding	Developer or content team
The page looks ready but taps do nothing briefly	Too much JavaScript, a busy tag manager or a slow widget	Tap the menu, form and booking controls during load	Developer, marketing or vendor
Text changes style or content jumps	Late fonts, images without reserved space, ads or injected banners	Reload while watching the headline, buttons and form fields	Developer or design team
The cookie notice appears late or blocks the first action	Heavy consent platform or a notice injected after layout	Compare a private first visit with a return visit after consent	Developer, privacy owner or consent vendor
Video or an embedded map delays the rest of the page	Large media download or third-party player loaded too early	Test the same page with the embed removed on staging	Developer or content team
Only logged-in, search or checkout pages are slow	Database queries, API calls or other backend work	Compare a static page with the slow dynamic page	Developer or platform host
The first visit is slow but the second is fast	Browser cache helps later visits; first-load assets are too heavy	Test twice, then repeat in private browsing	Developer or host
One region is slow while another is fine	Origin is far away, CDN coverage is weak or caching is bypassed	Test from two locations and review CDN cache status	Host or infrastructure provider

This table is a starting hypothesis, not a verdict. “Compress images” is useful only if images are actually holding up the page. A slow database will not be repaired by changing a JPEG to WebP.

Why mobile exposes problems that desktop hides

A modern laptop has a faster processor, more memory and often a steadier connection than an ordinary phone. It can hide the cost of downloading and running a large JavaScript bundle. Mobile latency also makes every trip to the server, image host, analytics service, chat widget or video provider more visible. If browser-side code assembles the content, the phone must run that code before it can show the answer.

That is why “it is fast on my desktop” is not a reliable test. It describes one powerful device, one connection and often a warmed browser cache.

A no-code ten-minute mobile test

Use the page that matters most to the business—a service page, booking page, product page or campaign landing page—not just the homepage.

Open it on a real phone in private browsing. This reduces help from a previous visit and shows the consent experience again. Start on Wi-Fi and watch for useful content, not the spinner.
Use the page while it loads. Open the menu, tap the main call to action, type in a form and scroll. Note ignored taps, delayed controls and content that moves under your finger.
Repeat on cellular. Turn off Wi-Fi and reload. Check whether an ordinary connection turns a small delay into an obvious one.
Test once more outside private mode. If the second visit is dramatically faster, caching is helping repeat visitors but the first visit still needs work.
Run the exact URL through PageSpeed Insights. Keep it on Mobile. Read “Discover what your real users are experiencing” first, if available, then “Diagnose performance issues.”
Record four items: the field-data status, the LCP element, any server-response warning and the largest script or image finding. Save the report URL or screenshots so the same evidence can be compared later.

Run PageSpeed two or three times before treating a small score movement as meaningful. Chrome’s Lighthouse scoring documentation notes that scores fluctuate with underlying conditions. A repeatable symptom and a clear bottleneck matter more than a three-point change.

Core Web Vitals in plain English

LCP: when the page’s main content arrives

Largest Contentful Paint usually tracks the largest visible headline, image or content block near the top. It asks, “When did this page start looking useful?” The current “good” threshold is 2.5 seconds or less at the 75th percentile of visits. Server delay, a late-discovered image, or blocking CSS and JavaScript can all slow it. Google’s current Core Web Vitals thresholds were verified on August 27, 2026.

INP: how quickly the page answers a tap

Interaction to Next Paint measures the delay from a tap, click or key press to the next visible update. The current “good” threshold is 200 milliseconds or less at the 75th percentile. A page can look loaded yet respond poorly while the phone runs JavaScript, marketing tags or a complex control. Standard Lighthouse load tests cannot reproduce a history of real interactions, so field data is especially important.

CLS: whether the page stays put

Cumulative Layout Shift measures unexpected movement: a button slides, text reflows, or a banner pushes the page after a visitor aims a tap. The current “good” threshold is 0.1 or less at the 75th percentile. CLS has no time unit; lower is better. Images and video without reserved dimensions, late embeds, consent messages and font swaps are common causes.

A page passes the Core Web Vitals assessment only when the available LCP, INP and CLS field measurements are all in the good range at the 75th percentile. That does not mean every visit was good. It means at least three quarters met each threshold in the measured distribution.

Where the delay usually comes from

The server and backend. Nothing else can begin until the initial HTML starts arriving. A slow application, overloaded shared hosting, expensive database query, external API, redirect chain or cache miss can consume much of the LCP budget before the browser has anything useful to display. A CDN can bring cached content closer to visitors, but it cannot help a response that is marked uncacheable or constantly sent back to a slow origin. Hosting and application behavior have to be investigated together.

Images, fonts and video. A 3,000-pixel photo displayed at 390 pixels wide wastes data and decoding work. Responsive sizes and AVIF or WebP can reduce transfer size; declared width and height reserve space. Too many font files can delay and reflow text. Video should use a lightweight poster and load its player when needed, rather than compete with the first screen.

Third-party code. Analytics, chat, reviews, maps, scheduling, A/B tests and consent systems make requests the site owner does not fully control. A tag manager’s cost depends on what teams put inside it. Web.dev’s tag-manager guidance explains that tags consume bandwidth and processing time, while injected content can shift layouts. Remove old tags rather than leaving them dormant.

JavaScript and rendering. The phone must download, parse, compile and execute JavaScript. Long tasks delay rendering and taps. Browser-side code that fetches and assembles essential content adds more steps. The fix may be smaller page-specific bundles, deferred features, or more ready-to-render HTML.

The fixes that usually matter most

Priority should follow measured delay, but this order catches the highest-leverage work on many business sites:

Fix the first response. Remove redirect chains, find slow database or API work, cache safe responses and confirm the CDN is serving the intended pages near the audience. If the initial document is late, every front-end improvement starts late too. This may require both development work and a review of hosting and delivery.
Make the main content arrive early. Identify the LCP element. Serve the right image dimensions and format, keep it discoverable in the initial page, and do not lazy-load an above-the-fold hero. Reduce styles or scripts that block it from rendering.
Remove or delay work that does not earn its place. Audit tag-manager containers, chat tools, review widgets, tracking pixels, consent integrations and experiments. Load a map, scheduler or video player only on pages—and at moments—where it is useful.
Cut JavaScript and rendering work. Deliver essential content in the first HTML where practical. Split large bundles by page, remove unused plugins and break up long tasks so taps can be acknowledged quickly.
Stabilize the layout. Reserve dimensions for images, video, ads and embeds. Give banners and consent controls predictable space or overlay them without pushing the main content. Use sensible font fallbacks and load only the font files the design needs.
Protect the improvement. Add performance checks to releases, monitor real-user Core Web Vitals and review third-party additions. Performance is a budget that can be spent again after the repair.

The aim is not a bare page. Images, type and useful tools can justify their weight. The discipline is to make every kilobyte and every third-party dependency explain what it contributes.

Things that make the score look better without making the site meaningfully better

Testing an empty page or the homepage when customers enter through a heavy service, product or booking page.
Removing a useful feature solely for the audit, then adding it back after the screenshot.
Optimizing only for the simulated test device while ignoring poor field data from real visitors.
Running tests until one unusually high score appears and presenting that run as the baseline.
Hiding a heavy widget behind an interaction when customers still need it immediately to complete the page’s main task.
Improving a secondary metric while the visible delay, ignored tap or layout jump remains.
Chasing 100 after the meaningful bottlenecks are fixed, instead of improving the content or enquiry path.

Google says Core Web Vitals are used by its ranking systems, but also says a good report does not guarantee top rankings and that pursuing a perfect score only for SEO may be a poor use of time. The same restraint applies to revenue claims: faster experiences can remove friction, but a score alone does not prove that sales increased. Measure completed forms, bookings or purchases alongside performance.

What evidence to request before and after a fix

Before approving work, ask the developer or host for a short diagnosis tied to a specific URL and symptom:

Field and lab results labeled clearly, including whether PageSpeed is showing page-level or site-wide data.
A waterfall or equivalent request timeline showing when the initial HTML, LCP resource, fonts and major third parties load.
Server-response time, cache status and CDN location for a cached and uncached request.
The identified LCP element, largest layout-shift causes and the scripts responsible for long tasks.
A list of third-party tools, who owns each one and whether it is essential on that page.
A stated hypothesis: “This delay is mainly the origin response,” not “We will optimize the site.”

After the change, request the same evidence under the same test conditions. The before-and-after comparison should show what changed in the request timeline, file weight or interaction trace—not just a higher circle score. Check the real phone again. Field data will not update instantly because PageSpeed reports a rolling 28-day window, so agree on an immediate lab check and a later field-data review.

For examples of production sites where the page has a clear job and the technology serves that job, see our work. If your own results are contradictory, a measured review can identify whether the first priority belongs with the code, the content, the third parties or the host.

Get a performance review grounded in evidence

CMT Web can review the pages your customers actually use, reproduce the mobile symptoms and give you a prioritized diagnosis before proposing a rebuild or a list of fixes. Start a conversation and include the slow URL, the phone or connection where you notice it, and any PageSpeed report you already have.