Slow website on mobile? What to check before you switch hosting

A website that is slow on mobile has to be diagnosed from its symptoms, because content that is slow to appear, buttons that respond late and a layout that shifts have different causes. Open PageSpeed Insights, see which metric has a problem, then find which part of the loading time is largest. A new host only helps if the server response really is that part.

Start with the page you rely on for enquiries or orders. Note the page address, device, network and the step that feels slow, so the developer can reproduce the same problem and measure the result of the fix.

Match the symptom to its metric

Symptom	Metric	Check first
The screen stays blank for a long time before anything appears	TTFB	Redirects, connection and server response
The heading is visible, but the main image stays blank for a long time	LCP	The LCP element and its four time parts
A button or menu feels delayed when tapped	INP	JavaScript work at the moment of the interaction
A button moves just as you are about to tap it	CLS	Space for images, banners and fonts

A hypothetical example: a visitor opens a service page on a phone. The heading appears quickly enough, but the main image stays blank for a long time. Once the image shows, the consultation button drops down and is hard to tap. There are two clues here: how long the main content takes to appear (LCP) and how stable the layout is (CLS).

Try the same page on a different network, then compare it with other pages on your website. If the problem appears only on one image or one template, note the difference. This narrows the search, although it is not enough to establish the technical cause.

How to read PageSpeed Insights

Enter the URL in PageSpeed Insights, then open the mobile results. Its documentation distinguishes two kinds of data, and each answers a different question.

Field data	Lab data
Source
The experience of eligible Chrome users over the last 28 days	A Lighthouse test under simulated conditions
Device
Visitors' real devices	A simulated mid-range device and mobile network
Figure shown
The 75th percentile	The result of a single test
Use
Judging the real experience	Finding causes and trying fixes

If there is not enough data for that URL, PageSpeed Insights shows origin data, meaning the whole site combined. If there is not enough origin data either, no real-user data is shown. Missing data does not prove that the site is fast, or that it is slow. In that case, use the lab results alongside checks on a real device, and note the limitation.

The 0 to 100 score at the top comes from Lighthouse. It is useful as a pointer, but it does not tell you which part is holding customers up, and the result can change from one test to the next. Save the first report along with its URL, so the comparison after the fix uses the same page under comparable conditions.

The thresholds Google uses

LCP, INP and CLS are the three Core Web Vitals. A page passes when all three are in the good range at the 75th percentile, with mobile and desktop data assessed separately. TTFB is not one of the Core Web Vitals, but web.dev gives a rough guideline for it. The thresholds below were checked on 1 November 2026. A value between the good and poor columns means the page needs improvement.

Metric	Good	Poor
LCP	Up to 2.5 seconds	Over 4 seconds
INP	Up to 200 ms	Over 500 ms
CLS	Up to 0.1	Over 0.25
TTFB	Up to 800 ms	Over 1,800 ms

LCP measures when the largest content appears, INP the response to interactions, CLS layout shift and TTFB the time until the first byte arrives. Suppose a hypothetical page has an LCP of 3.8 seconds, an INP of 280 milliseconds and a CLS of 0.18. All three fall in the needs-improvement range, short of the good threshold by 1.3 seconds, 80 milliseconds and 0.08. Those three gaps are not added up into one score, because their units and purposes differ.

Check where each figure comes from as well: page or origin data, field or lab. INP needs an interaction, so a Lighthouse result from loading the page cannot stand in for field INP.

The four parts of LCP reveal the cause

The LCP guide from web.dev splits LCP into four parts that add up to the full LCP time. This breakdown appears in the LCP diagnostics in PageSpeed Insights, and it is where you can see whether hosting is a likely suspect.

Part (guideline share)	What it means and what to check
TTFB, about 40 percent	Time until the first byte of HTML arrives. Check redirects, connection and server response.
Resource load delay, under 10 percent	The wait before the browser starts downloading the image. Check when the browser discovers the image.
Resource load duration, about 40 percent	Time spent downloading the image. Check file size, format and distance to the server.
Element render delay, under 10 percent	The wait from download to display. Check for render-blocking CSS and scripts.

Back to the hypothetical example. The 3.8-second LCP breaks down into a TTFB of 0.6 seconds, a load delay of 1.9 seconds, a load duration of 0.9 seconds and a render delay of 0.4 seconds. TTFB is still under 0.8 seconds, while the load delay takes half the time, far above the guideline.

If a new host cut TTFB to 0.3 seconds, LCP would only drop to 3.5 seconds. If the image were discovered earlier and the load delay fell to 0.3 seconds, LCP would come down to 2.2 seconds and reach the good range. In this case, money spent on moving hosts would not address the cause.

This breakdown comes from lab testing, so its figures can differ from field data. The shares in the table are relative guidelines too, and fixing one part can push time into another. So measure again after every change.

What to check with your developer, in order

Main image

Ask the developer to identify the LCP element, then check its file size, display size, format and when the browser starts downloading it. The LCP image must not be lazy-loaded, because its request is then only sent after the layout has been calculated. The browser finds the image earlier if its address is already in the initial HTML or requested through preload, whereas an image inserted by JavaScript is found later. For an image that is almost certain to be the LCP element, web.dev recommends fetchpriority="high".

Compressing the image helps if file size really is the problem. If the browser only finds the image after a chain of JavaScript has run, a smaller file does not solve that delay.

Server response and redirects

TTFB covers redirects, DNS lookup, connection and server response, so a high figure is not necessarily the host's fault. First check for unnecessary redirects, and whether the server does heavy processing on every visit.

Third-party scripts

List the chat, tracking, video and widget scripts that load, then ask what business purpose each one serves. Test changes on a copy or in a test environment, so that removing one script does not break a form, a payment or a measurement you still need.

Interaction

Try opening the menu, filling in a form and pressing the main button while the page is still loading. The INP guide from web.dev suggests this because the browser's main thread is often busiest during loading. Note the interactions that lag so the developer can trace them. Common causes are long JavaScript tasks and large scripts that run when the page opens.

Layout

For elements that shift, the CLS guide from web.dev recommends width and height attributes on images and videos, plus space reserved in advance for banners, ads and content that arrives later. Fonts that swap while loading can also move text.

When it makes sense to switch hosts

Moving hosts is worth discussing once the server response is proven to be the bottleneck. Start with TTFB in the field data. If it does not exceed 800 milliseconds, hosting is not the starting point. If it does, first remove unnecessary redirects and processing. Next, see whether simple pages are slow too, because if only one heavy page is slow, that page is what needs checking. If the hosting plan's resource limits really are being reached, there is a measurable reason to change the plan.

How to confirm the fix worked

1. Choose the most affected page and customer task.
2. Keep evidence of the symptom and the baseline measurements.
3. Agree on one fix, with a reason the report supports.
4. Retest the contact and transaction flows after the change.
5. Compare lab results straight away, then watch the rolling 28-day field data.

Include one service page and one page with a form in the check, because a smaller homepage image will not necessarily fix a product page with a different gallery. A log with five columns is enough: URL, symptom, starting value, change and test result.

If you need regular checks, see our website maintenance service. If the problem also involves page structure or user flow, bring this diagnosis with you when you discuss our website redesign service.