If your website is slow on mobile, the cause is almost always one of a short list: an oversized hero image or video, too many third-party scripts like chat widgets and trackers, a heavy page builder or plugin stack, slow hosting, or web fonts and stylesheets that block the page from drawing. Phones have less processing power and slower connections than desktops, so these problems hit mobile visitors hardest.
To find out which one is hurting you, run your page through Google’s free PageSpeed Insights on the Mobile tab, read the real-user (field) data before the score, then look at what the report says is slowing your Largest Contentful Paint. The rest of this guide walks through that process and the fix for each common culprit.
Step 1: Run PageSpeed Insights on mobile
Go to pagespeed.web.dev, paste in the address of the page you care about most (usually your homepage or your best-selling service page), and make sure the Mobile tab is selected. Test individual pages, not just the homepage: a product page with a big gallery can behave very differently from a simple contact page.
According to Google’s PageSpeed Insights documentation, the lab test for mobile simulates a mid-tier phone on a throttled mobile network. That is deliberately harsher than your own new phone on office Wi-Fi, and it is closer to what many of your real visitors have. If the site feels fast to you but the report says otherwise, the report is usually describing your customers more accurately than you are.
Step 2: Read field data before the score
The top section of the report, “Discover what your real users are experiencing,” is field data. It comes from the Chrome User Experience Report and summarises real visits over the previous 28 days. If your page does not have enough traffic, PageSpeed Insights falls back to data for your whole site (the origin), and if there is not enough of that either, the section is simply missing.
The lower section, with the 0 to 100 score, is lab data: one simulated load in a controlled environment. Google says a score of 90 or above is good, 50 to 89 needs improvement, and below 50 is poor. The lab test is great for debugging because it lists specific problems, but it can vary between runs and may not capture every real-world bottleneck. Use field data to decide whether you have a problem and lab data to work out why.
In the field data, focus on the three Core Web Vitals. Google’s web.dev thresholds are: Largest Contentful Paint (how quickly the main content appears) good at 2.5 seconds or less and poor above 4.0 seconds; Interaction to Next Paint (how quickly the page responds to taps) good at 200 milliseconds or less and poor above 500 milliseconds; and Cumulative Layout Shift (how much things jump around) good at 0.1 or less and poor above 0.25. Each is judged at the 75th percentile of page loads, so most of your visitors, not just the lucky ones, need a good experience.
Culprit 1: A huge hero image or a video with no poster
On most small-business sites, the Largest Contentful Paint element is the big banner image or video at the top of the page. If that file is several megabytes, the phone has to download all of it before your visitor sees anything meaningful. This is the most common reason for “largest contentful paint too slow.”
Fixes: resize the hero image to the size it is actually displayed at, compress it, and serve it in a modern format. Google’s guidance says WebP and AVIF generally compress better than JPEG and PNG and should be used where possible. Add fetchpriority="high" to that one image so the browser fetches it early, and never lazy-load it; web.dev states plainly that lazy-loading the LCP image always adds unnecessary delay. If the hero is a background image set in CSS, the browser discovers it late, so preload it or switch it to a normal image tag.
For background videos, ask whether you need one at all on mobile. If you keep it, give it a lightweight poster image. Google counts a video’s LCP from the poster image or the first frame, whichever is earlier, so a small poster lets the page look ready while the video loads.
Culprit 2: Too many third-party scripts
Chat widgets, analytics, heatmaps, ad pixels, review badges, cookie banners and embedded social feeds each load their own code from someone else’s server. Individually they seem harmless. Together they compete with your own content for the phone’s limited bandwidth and processor, and they are a frequent cause of poor Interaction to Next Paint because the phone is busy running their code when a visitor taps a button.
Fixes: list every script on the page (the lab report’s “Reduce the impact of third-party code” section helps) and remove anything nobody looks at. Keep one analytics tool, not three. Load chat widgets only after the visitor interacts or after the page has finished loading, and replace live social feeds with a simple link or a static screenshot. Removing code is the most reliable speed fix there is.
Culprit 3: Heavy page builders, themes and plugins
Drag-and-drop builders and all-in-one themes often ship CSS and JavaScript for every feature they offer, whether your page uses it or not. Add a slider plugin, a gallery plugin, a forms plugin and a popup plugin, and a phone may have to download and process a lot of code before it can show a simple service page.
Fixes: deactivate and delete plugins you do not use, replace several single-purpose plugins with one that covers the job, and avoid sliders and carousels in the first screen. Check whether your builder has settings to load assets only on pages that need them. If a theme is fundamentally bloated, a leaner theme or a rebuild can do more than any amount of tuning.
Culprit 4: Slow hosting and server response
Nothing can appear until your server sends the first byte of the page. Google’s web.dev guidance suggests most sites aim for a Time to First Byte of 0.8 seconds or less, calling that a rough guide rather than a hard rule. A slow TTFB eats into your 2.5-second LCP budget before a single image starts downloading. Cheap overcrowded shared hosting, no page caching, chains of redirects and a server far from your customers are the usual causes.
Fixes: turn on page caching, remove unnecessary redirects (for example, http to www to https in separate hops), and use a content delivery network so files are served from a location near the visitor. If your TTFB stays high after caching, it is often time to move to better hosting.
Culprits 5 and 6: Render-blocking files and web fonts
Stylesheets and scripts in the head of the page can stop the browser from drawing anything until they finish loading. Fixes: add defer to scripts that do not need to run immediately, remove unused CSS where your platform allows it, and avoid loading large libraries for small effects.
Web fonts can delay text or make it jump when the custom font replaces the fallback, which hurts both LCP and CLS. Google’s font guidance is to use fewer fonts (the fastest font is one that is never requested), serve WOFF2, use font-display: swap while making sure the font arrives early enough not to cause a shift, and preload the one or two fonts the first screen needs. For body text, a system font costs no download at all.
While you are there, give every image and video width and height attributes (or a CSS aspect ratio). Web.dev lists media with unknown dimensions as a common cause of layout shift, and reserving the space stops the page from jumping as it loads.
Be realistic about speed and SEO
Google confirms that Core Web Vitals are used by its ranking systems, but it also says it always seeks to show the most relevant content even when page experience is sub-par, and that good Core Web Vitals results do not guarantee top rankings. Speed is one signal among many. A fast page with thin, unhelpful content will not outrank a slower page that answers the question better.
The stronger reason to fix mobile speed is your customers. A slow page means people give up before they see your phone number, booking button or prices. After making changes, re-test in PageSpeed Insights for the lab view, and remember that field data covers 28 days, so give real-user numbers a few weeks to reflect your work.
If you would rather not manage any of this yourself, OneSol Max is a done-for-you small-business website: we build it with you on your own domain, include a CRM and handle the SEO, and a developer assigned to you keeps the site running and fixes problems like these as they come up. It is $1 for the first month, then $29 a month. We will not promise a particular PageSpeed score, because no honest developer can, but we will keep the common culprits above out of your site.