Guide

Your website is slow on phones: why and how to fix it

Find out what slows your site down on phones and fix it one change at a time. Measuring takes minutes and the first fixes need no developer.

Last updated: October 8, 2026

The short answer

A website is slow on phones for a handful of usual reasons: photos far larger than the screen needs, too many scripts and plugins, outside widgets that load last, and content that jumps because no space was reserved for it. Measure first, on a real phone and with PageSpeed Insights, which reports three numbers: LCP, INP and CLS. Google’s “good” targets are LCP up to 2.5 seconds, INP up to 200 milliseconds and CLS up to 0.1, for at least three out of four visits. Then fix in order of effect: resize and compress images, load the main image first, remove what you do not use, delay outside widgets and reserve space for images and embeds. It is worth the effort: Google/SOASTA research found that the chance a mobile visitor leaves is 32% higher when a page takes 3 seconds to load than when it takes 1 second.

Watch it in under a minute

A short video of the problem and its fix. Captions are in the video.

In this guide

Who this is for

You run a website and it feels slow on a phone: the page stays blank for a while, the text jumps as things load, or a menu reacts late when you tap it. Maybe it looks fine on your laptop and a visitor or a colleague tells you otherwise. Or a speed test came back red and you do not know where to start.

This guide works for WordPress, site builders and hand-built or static sites. The first steps need no technical background: measuring, and resizing images. Later steps touch plugins, scripts, fonts and hosting, so you may need whoever built or looks after your site.

What “slow” means, and why phones show it first

“Slow” is not one thing. Google describes the experience with three measurements, the Core Web Vitals, and publishes a target for each. A page counts as “good” when it meets all three for at least 75% of page loads, measured separately for phones and for computers (web.dev):

LCP (Largest Contentful Paint): how long until the biggest thing on the screen, usually the main image or the headline, is visible. Good: up to 2.5 seconds.
INP (Interaction to Next Paint): how long the page takes to react when someone taps, clicks or types. Good: up to 200 milliseconds.
CLS (Cumulative Layout Shift): how much the content jumps around while loading. Good: up to 0.1.

Phones show problems first because they have less processing power than a laptop and often a weaker connection, so a heavy page or a pile of scripts costs more time there. And waiting costs you visitors: in Google/SOASTA research from 2017, the probability that a mobile visitor leaves was 32% higher when a page took 3 seconds to load instead of 1 second.

How to tell which cause applies

Run step 1 first, then match what you see:

LCP is over 2.5 seconds. The main image or headline arrives late. Likely causes: an oversized or badly prepared main image, a slow server, or text that waits for a font. Go to steps 2, 3, 4, 8 and 9.
INP is over 200 milliseconds. Taps and menus feel laggy. The phone is busy running scripts. Likely causes: too many plugins and scripts, or heavy outside widgets. Go to steps 6 and 7. Google’s guide to INP explains the technical side for a developer.
CLS is over 0.1. Things move while the page loads and people tap the wrong button. Likely causes: images and embeds without reserved space, banners or ads that appear late, fonts that swap. Go to steps 5 and 8.
Fast on your laptop, slow on a phone. Normal, because a laptop on fast Wi-Fi hides the problem. Test on a phone on mobile data (step 1) and start with images (step 2) and scripts (step 6).
Only some pages are slow. Look at what those pages have that others do not: a slider, a video, a map, a gallery or a widget. Go to steps 4, 5 and 7.
Lab and field results disagree. Lab data is a single simulated test, field data is what real visitors experienced. Trust the field data for the verdict and use the lab test to find causes (why they differ).
No field data is shown. The page does not have enough visits yet. Use the lab test and a real phone, and check again after a few weeks.

Steps to fix it

Measure on a real phone and write down the numbers. Open PageSpeed Insights, enter the address of your home page and of one or two other important pages, and read the Mobile tab. The top part, “Discover what your real users are experiencing”, is field data from real Chrome visitors over the past 28 days. The lower part is a lab test with Lighthouse, a simulated run that lists concrete problems (how the two differ). Write down LCP, INP and CLS for each page. If your site is verified in Google Search Console, its Core Web Vitals report shows the same data grouped by similar pages, so you see which kinds of pages have a problem. Then open the site yourself on a phone with Wi-Fi switched off and see how it feels. Field data covers 28 days, so it changes slowly after a fix. Use the lab test to check a change right away.
Resize and compress your images. Oversized photos are the most common cause. A photo straight from a camera or a stock library can be several thousand pixels wide, while a phone screen shows it a few hundred pixels wide. Make each image about as large as the largest size it is shown at, then compress it. Offer several sizes with srcset so a phone downloads the small one (responsive images). In WordPress, insert images at the size they are displayed instead of “Full size”. An image plugin or your host can often resize and convert images for you.
Use a modern image format. WebP and AVIF can compress better than JPEG and PNG, so the same picture loads faster. Convert your images and keep a JPEG or PNG fallback for browsers that do not support the new format, if your tool does not do that for you (choosing a format). Do not enlarge or re-save an already compressed image over and over, because quality drops each time. Convert from the original file.
Make the main image arrive first, and lazy-load the rest. The main image at the top of the page (often the LCP element) should load as early as possible. Put it in the page as a normal <img> rather than as a CSS background or inside a slider that loads by script, and add fetchpriority="high" so the browser fetches it first (optimize LCP). Never set loading="lazy" on it. Images further down the page are the opposite: add loading="lazy" so they load only when the visitor scrolls near them (lazy loading). WordPress has done both automatically for the likely main image since version 6.3 (WordPress announcement), but themes, sliders and page builders can switch it off, so check the page source.
Reserve space so nothing jumps. Give every image and video width and height attributes, or a CSS aspect-ratio, so the browser leaves the right gap before the file arrives (optimize CLS). Do the same for embedded maps, videos and widgets: set their size, and lazy-load those that start below the first screen (embed best practices). Cookie notices, announcement bars and ads that appear late and push the content down are a classic cause of layout shift. Give them a fixed space, or show them as an overlay.
Remove plugins and scripts you do not use. Every plugin, tracking tag and add-on can bring its own scripts and styles, often on every page. List what is installed, delete what nobody uses, and replace heavy ones with a lighter option. Remove one at a time and measure again, so you know which one made the difference. Take a backup first. In WordPress, deactivating a plugin on a staging copy of the site is safer than on the live site. Lighthouse in PageSpeed Insights lists unused JavaScript and CSS, which points you to the culprits.
Delay outside widgets. Chat bubbles, social feeds, review badges, maps, video players and advertising tags load code from other companies, and they often load last and compete with your own content. Load only what you need, and load it late: add async or defer to scripts, or load a widget only after a tap, with a simple preview image in its place (third-party JavaScript). Lighthouse flags third-party code that blocks the main thread for 250 milliseconds or longer (details). Ask of each widget: does anyone use it?
Load fonts sensibly. Use few font families and weights, and host the font files on your own domain in WOFF2 format, with only the characters you need. Set font-display so text shows right away in a fallback font instead of staying invisible, and preload only the one or two fonts the first screen needs (font best practices). A swapped font can move the text, so pick a fallback font of a similar size.
Add caching and a content delivery network. A slow server delays everything that follows. Caching lets the server or the visitor’s browser reuse a page instead of building it again, and a content delivery network (CDN) serves files from a location near the visitor. Most good hosts and WordPress caching plugins offer both. Check that updates still show up after you turn caching on (LCP and server response time).
Measure again and keep watching. Repeat step 1 with the same pages and compare the numbers. Change one thing at a time, so you can see what helped. Check again in a month, because field data takes 28 days to catch up, and new plugins, large uploads and new widgets slowly undo the work. Put a speed check in the calendar each quarter, or run it before every larger content update.

When to get help

Bring in someone experienced if:

the numbers stay red after you have worked through steps 1 to 9
you cannot reach the theme, hosting or plugin settings, or do not know who can
the site is built with custom code or a page builder that nobody maintains
the slowness comes from the server itself, for example the first byte takes seconds to arrive
slow pages cost you enquiries or sales, as on landing pages for advertising or a shop, and you want a setup that is measured and monitored instead of fixed once