How to Speed Up a Slow Website: Measure the Right Number, Then Fix It in This Order

Picture a typical situation. A Kharghar furniture showroom owner opens her website on her phone while standing in her own shop, on mobile data, to show a customer a sofa range. The screen stays white for several seconds, then a huge banner slides in, the text jumps down, and the customer has already turned back to the floor sample. She has a website. It just does not help at the moment it is needed.

That moment is mostly a mobile one. Statcounter shows 77.3% of web traffic in India came from mobile devices in September 2026. So the question this article answers is practical: how do you find out why your site is slow on a phone, and which fixes are worth paying for first?

1. Measure the right number first

Open PageSpeed Insights, enter your homepage and look at the top section before the big coloured score. Google’s documentation explains that PageSpeed Insights reports two kinds of data. Field data shows “true, real-world user experience” from Chrome users over the previous 28 days. Lab data comes from Lighthouse running “a simulated load of a page on a single device and fixed set of network conditions,” and is meant for debugging.

The score out of 100 is the lab result. Google labels 90 or above as good, 50 to 89 as needing improvement and below 50 as poor. It is useful as a to-do list, but it is a simulation of one device on one connection. Your real visitors, in the field data, are what Google uses to judge experience in Search Console’s Core Web Vitals report.

If your site does not have enough traffic for field data, PageSpeed Insights will say so and show lab data only. That is common for small business sites. In that case, use the lab numbers, and also do the simplest test there is: open your site on a mid-range Android phone on mobile data, not office Wi-Fi, and time how long until you can read the main heading.

2. Work out which metric is failing

“Slow” can mean three different things, and each has different causes. Google’s Core Web Vitals split it out.

Sources: Search Console Help, Core Web Vitals report for LCP, INP and CLS; web.dev, Time to First Byte for TTFB. The “usual cause” column is my experience, not Google data.

Google assesses these at the 75th percentile of visits, separately for mobile and desktop. As web.dev puts it, a page passes when it “meets the recommended targets at the 75th percentile.” In plain terms, three out of four visits need to be good, so a fast experience on your own new phone does not count for much.

INP is the newest of the three. It replaced First Input Delay as a Core Web Vital in March 2024, as announced on web.dev, so older speed guides that talk about FID are out of date.

3. Fix the hero image first

On most business websites, LCP is an image: the big banner, the product photo or the team picture at the top. The HTTP Archive’s Web Almanac 2024 found the LCP element was an image on 73% of mobile pages it measured. Fix that image and you usually fix LCP.

Source: HTTP Archive Web Almanac 2024, Page Weight (October 2024 crawl) and Performance chapters. Global data, not specific to India.

Images are the largest share of that weight. Here is what to do, in order:

1. Resize to the size it is shown. A banner displayed 400 pixels wide on a phone does not need to be a 4,000-pixel camera original. This single step often removes most of the weight.
2. Use a modern format. Google says lossy WebP images are 25 to 34% smaller than comparable JPEGs, and lossless WebP is 26% smaller than PNG. Most current CMS platforms and image plugins can convert automatically.
3. Never lazy-load the hero. web.dev is blunt: “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay.” Yet the Web Almanac found 16% of mobile pages with an image LCP were lazy-loading it, often because a plugin applied lazy-loading to every image.
4. Tell the browser it matters. web.dev suggests setting fetchpriority="high" on the image likely to be the LCP element, while warning that doing it on “more than one or two images makes priority setting unhelpful.”
5. Lazy-load everything below the fold. Use loading="lazy" “only for images outside the initial viewport,” in web.dev’s words. Gallery and footer images can wait.

Sliders deserve a special mention. A five-image carousel at the top of a homepage loads several large images to show one, and usually adds JavaScript as well. I recommend replacing it with one strong static image and a clear headline. It is faster, and visitors rarely wait for slide three.

4. Fix the server: hosting, caching and a CDN

Every other part of loading waits for the server’s first response. web.dev’s LCP guide breaks LCP into four parts and suggests roughly 40% of it should go on that first response (TTFB) and about 40% on loading the main image, with very little time left for delays. If your TTFB alone is close to two seconds, no amount of image work will get LCP under 2.5 seconds.

Hosting

Crowded shared hosting is the most common cause of slow TTFB I see on small business sites. Hundreds of sites share one server, and your pages wait their turn. Check where your server is located too. If most customers are in Mumbai and the server is on another continent, every request travels further than it needs to.

Page caching

On WordPress and similar systems, each page is normally built from the database on every visit. Page caching saves a ready-made copy and serves that instead, which is usually the cheapest large improvement to TTFB available. Many hosts include server-level caching; otherwise a well-maintained caching plugin does the job. Use one caching tool, not three that fight each other.

A CDN

A content delivery network keeps copies of your images, styles and scripts on servers in many cities and serves each visitor from the nearest one. For a site whose customers are all in one city with a server nearby, the gain is modest. For a business selling across India or abroad, it is often worth setting up, and several CDNs have free tiers.

See also: If you are weighing a rebuild because the platform itself is the bottleneck, see WordPress vs a custom website.

5. Cut the scripts that make taps feel slow

A poor INP means the phone is busy running code when the visitor taps. web.dev’s INP guide explains that script work “can introduce long tasks on the main thread,” and that input can be delayed by scripts “loading, parsing and compiling.” Its general advice is to “do as little work as possible” in response to each interaction.

On business sites, the heavy code is rarely your own. It is usually a stack of add-ons, each installed for a good reason at some point:

• A live chat widget, plus a WhatsApp button plugin, plus a pop-up tool.
• Several tracking tags: analytics, an ads pixel or two, a heatmap tool from a trial nobody cancelled.
• Page builder and theme code that loads features on every page whether used or not.
• Embedded maps, review widgets and social feeds on the homepage.

Go through the list and ask, for each one, whether anybody has looked at its data or used its feature in the last three months. Remove the ones nobody uses. For the ones you keep, ask your developer whether they can load after the page is usable rather than at the start. A Google Map, for example, can be shown as a static image that loads the live map only when tapped.

6. Stop the page from jumping

Layout shift is the experience of tapping “Call now” just as a banner loads and pushes the button down, so you tap something else. web.dev lists the most common causes as images without dimensions; ads, embeds and iframes without dimensions; dynamically injected content; and web fonts.

• “Always include width and height size attributes on your images and video elements,” web.dev says, so the browser reserves the right space before the file arrives.
• Reserve space for anything that loads late, such as an offer bar, cookie banner or embedded video, for example with a minimum height in CSS.
• Load your main web font early (web.dev recommends preloading critical fonts) and limit the number of font weights you use.
• Avoid inserting new content above what the visitor is already reading.

7. Does a faster site actually help the business?

The strongest public evidence comes from controlled tests rather than broad statistics. In a case study published on web.dev, Vodafone ran an A/B test on a landing page with traffic split 50/50 between an original and a version optimised for Core Web Vitals. The optimised version had a 31% better LCP and produced 8% more sales, with a 15% better lead-to-visit rate. Its changes are familiar ones: less render-blocking JavaScript, server-rendered HTML and a resized hero image.

That is one large company’s test on paid traffic, not a law for every site, and I would not promise any business a specific uplift from speed work. But it was a clean experiment where speed was the only difference, which is rarer and more convincing than the round-number statistics often quoted in speed articles.

And rankings?

Google’s Core Web Vitals page says it “highly recommends” good Core Web Vitals “for success with Search” and that they align with what its core ranking systems seek to reward. Its page experience page adds the important balance: there is “no single signal,” and Google “always seeks to show the most relevant content, even if the page experience is sub-par.” My reading: speed can help you edge past a similarly relevant competitor, but it will not lift a page that does not answer the search.

See also: Speed is one item in a wider check. Our SEO audit guide shows where it sits among the other fixes.

Where this advice breaks down

• Low-traffic sites have no field data. You will be working from lab scores and your own phone tests, which are less reliable. Do not panic over a single lab run; run it three times and look at the pattern.
• A score of 100 is not the goal. Getting from 85 to 100 in the lab can take a lot of developer time for little visible change. Once the field metrics are in the good range, spend effort elsewhere.
• Some slowness is a platform limit. Heavily customised page-builder sites can only be slimmed so far. Past a point, a rebuild on a lighter setup is cheaper than endless tuning.
• Optimisation plugins can break things. Aggressive script deferring or combining can stop menus, forms or checkout working. Test every key action, especially the enquiry form, after each change.
• Speed does not fix a weak offer. A fast page that does not show prices, location or a clear way to contact you will still lose the visitor.

Your speed checklist

For the showroom owner in the opening scene, the test that matters is simple: can she open her site on mobile data in front of a customer and have the sofa range on screen before the customer looks away? Fix the one or two things standing in the way of that, and most of the score takes care of itself.