Why is my website slow on mobile, and how do I fix it?

Use PageSpeed Insights, from Google. It gives two kinds of data. Lab data comes from running Lighthouse on your page in a simulated environment, and a score of 90 or above counts as good, 50 to 89 needs improvement, and below 50 is poor. Field data comes from real Chrome users over the previous 28 days.²

The two can disagree. Google says lab data is useful for debugging because it is collected in a controlled environment, but it may not capture real-world bottlenecks.² A page with too little traffic may have no field data of its own. PageSpeed Insights then falls back to figures for the whole site, and if the site is short on data too, it shows none.²

The targets to know are the three Core Web Vitals. Largest Contentful Paint (LCP) measures loading, and Google says it should happen within 2.5 seconds of when the page starts loading. Interaction to Next Paint (INP) measures interactivity, such as how fast the page reacts to a tap, and the target is 200 milliseconds or less. Cumulative Layout Shift (CLS) measures visual stability, which is how much the page jumps around while it loads, and the target is 0.1 or less.¹

Google says a good threshold to measure is the 75th percentile of page loads, split by mobile and desktop.¹ In plain terms, at least three of every four visits should meet each target. PageSpeed Insights reports on both mobile and desktop, so read the mobile numbers if your customers find you on their phones.²

Our free website check runs these tests and tells you which standard your site misses. If the page is fast and nobody calls, see why isn't my website getting calls or leads.

Google breaks the load of a page's largest item into four parts. The first is the time to first byte, which is how long the browser waits for the server to start answering. The second is the delay before the browser starts loading that item. The third is the time it takes to load it. The fourth is the time between the item finishing loading and showing on the screen. Google puts the best split at about 40% for the first byte, under 10% for the delay, about 40% for loading and under 10% for the wait to show, and adds that these shares are guidelines, not strict rules.³ The biggest part tells you where to start. These are the causes Google's pages point to:

• A slow server response. Google's rough guide for time to first byte is 0.8 seconds or less, and it calls values over 1.8 seconds poor. The time adds up from redirects, the lookup of your address, the secure connection and the wait for the first byte, so a delay in any of them counts.⁴

• Redirects. Google says to always minimize the number of redirects a visitor must wait through, and names visitors who arrive through several redirects, from ads or link shorteners for example, as a cause of a slow first byte.³

• A late-starting biggest image. Google says the image should be findable in the first HTML the server sends. A picture added later by JavaScript, or set as a CSS background, starts loading late. Lazy-loading it, which means holding it back until it is nearly on screen, always adds delay.³

• Styles and scripts that block the page. Google says the whole page can be blocked from showing by stylesheets or synchronous scripts, and that it is almost never necessary to add synchronous scripts.³

• A big image file. Google lists serving the right image size, using a modern format such as AVIF or WebP, and compressing the file. It also says the time to load the item tends not to be a significant bottleneck for most sites.³

• Scripts from other companies. Third-party code means scripts that load from another company's server, like a chat box, an ad or a tracker. Chrome's documentation says third-party code can significantly impact load performance, and advises reducing it and deferring its loading so your own content comes first.⁵

Google gives an example of a page where switching the biggest image to AVIF or WebP would not improve the largest-content time, because the time would just shift to another part. It tells you to check your real-user data to decide which part to focus on.³ That is why a smaller image alone doesn't always help.

Google's guide has fixes for each of the four parts. Start with the one that is your biggest.

• First byte is slow. Google says reducing latency in connection setup and on the backend can lower it.⁴ Keep redirects short. Unique parameters added to web addresses for analytics can keep a content delivery network (CDN) from using its saved copy of your page, so the request goes back to your server.³ For pages the server builds for each visit, the extra work can slow the first byte, and Google calls prerendering, which means building pages ahead of time, generally a better choice for performance if your setup allows it.³

• The biggest item starts loading late. Put the image in the page's HTML so the browser finds it at once, and do not lazy-load it. A setting called fetchpriority can tell the browser which image matters most, but Google cautions against giving a high priority to more than one or two images.³

• The biggest item takes long to load. Serve the image at the right size, use a modern format such as AVIF or WebP, and compress it. Google says serving images from the same origin as your pages avoids an extra connection, that a CDN gets files closer to your visitors, and that efficient cache settings let repeat visits reuse them.³

• The biggest item loads but shows late. Remove unused styles, defer the ones the first screen doesn't need, and shrink the rest. Inline a stylesheet only if it is small, and a script only if it is very small. Google names large JavaScript files as the most common reason the browser is too busy to draw the page.³

• Scripts from other companies. Remove the ones you don't need and defer the rest.⁵

If your site sits on a service that controls these settings, you may not be able to change all of them. That is worth knowing before you pay for more of the same.

1. Run PageSpeed Insights on your own page address, open the mobile results, and write down the scores.

2. Find the biggest of the four parts. If you can't tell which it is, that is a good time to ask for help.

3. Fix that part using the list above, then test again. Google's own example shows that a fix to the wrong part can leave the time where it was.

4. Remove third-party scripts you don't need, and delay the ones you keep.

5. Test several pages, because one page doesn't speak for the site.

6. If a builder or a host controls what the tool flags and you can't change it, that is useful to know before you pay for more of it.

We scanned every Classic kit look on October 21, 2026: 206 kits and 618 looks. None loads anything from another host when the page opens, and none has a script file. A look folder runs from 85 to 1,082 KB, and the median is 172 KB.⁶ A kit is a set of plain files, so nothing is built on a server for each visit, which suits Google's advice on prerendering where your setup allows it.³ Your own photos and your host still decide how fast it ends up.

On October 20, 2026, six of our own pages scored 95 to 100 for performance in PageSpeed Insights on the phone setting.⁷ We also checked 11 web design sites that came up in Google searches for Brooklyn, Queens and the Bronx. On the same kind of phone test, 9 of the 11 scored under 90 for performance, and the middle score was 60.⁸ Slow pages are common, even on the sites of people who build sites for a living.

Kits for businesses where phone traffic matters most include Plumber, Hair salon, Cleaning service, Electrician, Landscaping and Auto repair. The whole list is at website kits.

When PageSpeed Insights flags things you don't understand, or the fixes sit inside a builder or a host you can't change. We help businesses fix slow sites and build fast ones. Tell us about your business. For what a site costs to build, see what a small business website costs. If Chrome also warns visitors about your connection, see why does my website say not secure.

The targets, the four parts of a load and the fixes come from Google's own documentation, linked below. Each page shows its own date, and the oldest was last updated in October 2024. The kit scan and the speed runs are our own, from files and results we keep, and no outside site is named. We sell website kits and help businesses with their sites, so we have a stake in this question.