What should I fix first to speed up my site on phones?
Fix the biggest, slowest thing first: on many small-business sites that's the large photo, slider or video at the top of the page. Then remove plugins and third-party scripts you don't need, make sure the server answers quickly with caching, and stop layout jumps. Measure on a phone before and after every change.
The short version
- Measure first, on a phone, for your home page and the pages that bring in work.
- Fix the top of the page: resize and compress the hero image, don’t lazy-load it, and replace sliders and autoplay video.
- Cut plugins and third-party scripts you don’t need, and delay the rest.
- Make the server quick with page caching and a content delivery network.
- Stop layout jumps and slow taps, then measure again.
Why does speed on phones matter so much?
Many of your customers find you on a phone. Pew Research Center’s mobile fact sheet, from a survey run in the first half of 2026, reports that 91% of U.S. adults own a smartphone and 16% are “smartphone-only” internet users with no home broadband.
Phones are often slower than the computer you build or check your site on. They have less processing power and are frequently on mobile data. A site that feels instant on office Wi-Fi can feel sluggish in a customer’s driveway, and a slow page costs you calls and form fills whatever it does for ranking.
How do I know whether my site is too slow?
Google’s Core Web Vitals are the most useful targets. The Web Vitals guide sets “good” at:
- Largest Contentful Paint (LCP): the main content appears within 2.5 seconds.
- Interaction to Next Paint (INP): the page responds to a tap within 200 milliseconds.
- Cumulative Layout Shift (CLS): a layout-shift score of 0.1 or less.
A page passes when 75% of real visits meet each mark, measured separately for phones and desktops. INP replaced First Input Delay as a Core Web Vital in March 2024, so older articles may still mention FID. Our answer on what Core Web Vitals are explains each one, and our answer on whether a low PageSpeed score matters explains why the 0 to 100 score is only a guide.
Step 1: How do I measure before changing anything?
Write down a starting point so you’ll know what helped.
- Test your home page and your most important service or booking page in our speed test or Google’s PageSpeed Insights.
- Note LCP, INP and CLS for mobile.
- If your site gets enough visits, check Search Console’s Core Web Vitals report for real-visitor data. Small sites often don’t have enough, which is normal.
- Find which element is the “largest contentful paint.” Most tools name it. It’s usually a hero image, a slider or a big headline.
Test the pages people land on and act on, not just the home page. A fast home page doesn’t help much if the booking page crawls.
Step 2: How do I fix the top of the page?
This is usually the biggest win. The top of the page is what visitors wait for, and on many small-business sites it’s a full-width photo, a slider of five photos or an autoplay video.
Fix the hero image
Google’s guide to optimizing LCP recommends:
- Serve the right size. A phone doesn’t need a 5,000-pixel photo straight off a camera. Our answer on how big images should be gives sizes.
- Compress it and use modern formats such as WebP or AVIF.
- Never lazy-load it. The guide says to “never lazy-load your LCP image.” Lazy-loading is for images further down the page.
- Give it high priority.
fetchpriority="high"on the main image tells the browser to fetch it early. The guide warns that setting it on more than one or two images makes it unhelpful. - Make it easy to find. If the image is a CSS background or loaded by a script, the browser finds it late. Preloading it fixes that.
Rethink sliders and video
Replace a five-image slider with one strong image, because a slider loads several large images instead of one. Replace autoplay background video with a still image, or load the video only when someone taps play.
Step 3: Which plugins and scripts should I cut?
After the hero, the next most common problem is too much code loading on every page.
Plugins (WordPress):
- Remove plugins nobody uses. It helps security too.
- Look for plugins that load on every page but are needed on one, like a form or gallery.
- Be wary of heavy page builders and all-in-one themes that load code you don’t use.
Our answer on how many plugins is too many explains how to decide which to keep and how to remove them safely.
Third-party scripts: chat widgets, tracking pixels, social feeds, review widgets, heat maps and old analytics tags all add weight, and many slow the response to taps.
- List every script and who added it.
- Remove anything nobody uses.
- Delay non-essential scripts, like chat, until after the page loads.
- Replace heavy embeds, such as a full social feed, with a link or a static image.
Step 4: How do I make the server respond faster?
Before the browser can show anything, the server has to answer. Google’s LCP guide suggests aiming for roughly 40% of the LCP time on that first response, as a guideline rather than a rule.
- Page caching. Serve pages from a cache instead of rebuilding them for every visitor. Good WordPress hosts and caching plugins handle this.
- A content delivery network (CDN). It serves files from locations near your visitors. The LCP guide calls a CDN “the best way” to cut the distance files travel.
- Fewer redirects. Each one adds a delay, so link straight to final addresses.
- Decent hosting. Crowded, bargain shared hosting can be slow whatever you do to the site. Our answer on what website maintenance includes explains how hosting and care differ.
Step 5: How do I stop the page jumping around?
Layout shift is when you go to tap a button and the page moves, so you tap the wrong thing. It’s what CLS measures.
- Images without set sizes. Give images a width and height so the browser reserves space.
- Banners and pop-ups that push content down. Reserve space, or show them without moving the page.
- Late-loading web fonts. Limit font files, and use settings that keep text steady while fonts load.
- Ads and embeds without reserved space.
Step 6: How do I make taps feel quick?
INP measures how fast the page reacts when someone taps a menu, button or form field. Slow INP usually comes from too much JavaScript running at once. Removing or delaying scripts in Step 3 helps most. Keep menus and accordions simple, and ask your developer to break up long-running scripts.
How do I ask a developer for speed work?
A clear request gets better results than “the site feels slow”:
Our home page and booking page feel slow on phones. Can you check mobile Core Web Vitals, tell us which element is the Largest Contentful Paint on each, and list the plugins and scripts that load on every page? We’d like a short plan in priority order before anything changes.
Ask for before-and-after numbers for each change, and ask for changes to be made on a test copy first. Delaying or combining scripts can break forms, menus or checkout, and you want to catch that before customers do.
What are the most common mistakes?
- Chasing a perfect lab score. Real-visitor numbers and a site that feels fast matter more.
- Installing three speed plugins. They can conflict and make things worse.
- Tiny tweaks before big ones. Trimming a few kilobytes of code won’t matter while a 4 MB hero image loads.
- Lazy-loading the hero image.
- Testing only on a fast office computer.
What if it’s still slow after these fixes?
Check whether the problem is the server: if the first response is slow on every page, caching or hosting is the likely cause. If real-visitor data hasn’t moved yet, wait. Field data covers the last 28 days, so improvements take a few weeks to show fully. If the theme or page builder itself is heavy, the honest answer may be a rebuild; our answer on whether to redesign or fix helps you weigh it. Our help article on why a website is slow covers quick checks.
How much does it cost, and how long does it take?
Testing is free. Fixes range from minutes, like compressing one image, to a rebuild for a heavy theme. Real-visitor data needs roughly four weeks to reflect a fix. Sites slow down over time as new photos, plugins and scripts arrive, so recheck monthly; our website care checklist includes it.
How does E-3 handle this?
The cause of slow sites we see most in our support records is page weight: photos and videos uploaded far bigger than the page needs. Our speed program works through this list in order, measures before and after, and tests speed fixes on a staging copy first. We’ll tell you what’s realistic after we look, and we won’t promise ranking changes.
Related questions
Common questions
- My site is fast on my office computer. Why test on a phone?
- Your office computer likely has a fast connection and plenty of power. Many customers are on a phone, sometimes on a weak signal, and Google measures phones and desktops separately. Test where your customers are.
- What's a good target?
- Google's Core Web Vitals: the main content showing within 2.5 seconds, taps answered within 200 milliseconds, and a layout-shift score of 0.1 or less, for at least 75% of real visits.
- Will a faster site rank higher?
- Speed is part of Google's page experience signals, but it won't lift a page above more relevant results. The surer benefit is that visitors don't give up waiting. We won't promise ranking changes from speed work.
Rather talk it through?
Call our team, or send a note and we’ll reply within one business day. No pressure and no jargon.