October 08, 2026
The fastest way to increase website loading speed is to shrink and delay what the browser has to download before it can paint the top of the page: images first, then JavaScript, then fonts and third party scripts. On most sites we audit, those four are where the waiting happens, and the fixes are cheaper than a new site.
Below are twelve fixes in the order we apply them, each with how to spot the problem, how to fix it and what it is usually worth. The numbers come from our own site, measured this week, because the lab score and the phone in your hand often disagree, and the disagreement tells you where to look.
One warning before the list. Measure on a phone over a throttled connection before you change anything, and again after. Most visitors to an Indian business site arrive on a mid range Android on mobile data, and a page that feels fine on office WiFi can take five seconds for them.
Use three tools, in this order.
PageSpeed Insights (pagespeed.web.dev) is free and gives two sets of numbers. The lab numbers come from a simulated slow phone in Google's data centre. The field numbers, shown at the top when there are enough visitors, come from real Chrome users on your site over the last 28 days. Read the field numbers first; they are what Google uses. The lab numbers are for finding what to fix.
Chrome DevTools on your laptop lets you throttle the network and the CPU. Open the Performance panel, set the network to a 4G profile and the CPU to a four times slowdown, and reload. This is the quickest way to see which file is blocking the page.
Your own phone, WiFi off, on mobile data, standing somewhere with two bars. Open the page you send ads to, not just the home page. Count. If you reach four before the text is readable, you have work to do.
The four numbers that matter are Largest Contentful Paint (LCP, the time until the biggest thing on screen appears; aim under 2.5 seconds), Cumulative Layout Shift (CLS, how much the page jumps; aim under 0.1), Interaction to Next Paint (INP, how fast the page responds to a tap; aim under 200 milliseconds) and Total Blocking Time (TBT, a lab measure of how long JavaScript locks the page). Article 27 explains how to read the full Core Web Vitals report.
Almost always one of six things, and usually more than one. The photos were uploaded straight from the camera at 3 MB each. The theme or page builder loads thirty scripts and stylesheets to show a heading. Nothing is cached, so every visit rebuilds every page. The hosting is the cheapest shared plan, on a server in another continent. There are six third party scripts for chat, analytics, pixels and a font service, each phoning home before your content shows. And the address redirects two or three times before it lands.
On a phone every one of these is worse, because each extra file is another round trip on a slower, less reliable connection. That is why a site can score well on desktop and badly on mobile with nothing changed except the device.
Our own site is the honest example, because we had all the numbers.
Google PageSpeed's mobile lab run gave LCP 5.5 seconds, TBT 359 milliseconds and CLS 0.251. Desktop the same day was LCP 1.4 seconds and CLS 0.004. The Coverage tab showed 141 KB of unused JavaScript on the home page. A crawl tool put site health at 61.
The CLS figure looked alarming, so we tested it on a real phone over a throttled connection and measured 0.006. The lab simulation was triggering a layout shift that a real device did not, because of when it painted the first screen relative to the animations. That is the case for checking a lab number against field data before spending days on it. The LCP and TBT figures, on the other hand, were real work, and they came down through the fixes below. Across three audits the crawl tool's site health went 61, then 84, then 95.
Spot it: the network panel shows images over 200 KB, or a hero photo wider than 2,000 pixels. Fix it: save each photo as WebP at the sizes the layout actually uses (we keep 640, 1024, 1200 and 1600 pixel variants) and let the browser pick with srcset. Worth: on most sites this is the single biggest LCP gain, and it costs nothing but an afternoon.
Spot it: text jumps down as photos load; CLS above 0.1. Fix it: put width and height attributes on every img tag and reserve space for embedded videos and maps with a fixed aspect ratio. Worth: this alone usually takes CLS from a fail to a pass.
Spot it: the Coverage tab in DevTools lists files that are mostly red. Ours showed 141 KB unused. Fix it: drop libraries loaded for one feature on one page, load page specific scripts only on that page, and delete the slider plugin nobody scrolls. Worth: lower TBT and a page that responds to the first tap.
Spot it: the source of a simple page has dozens of script and style links. Fix it: disable the builder's modules you do not use, or, if the site is due a rebuild, build the pages as plain HTML and CSS with components. Worth: page builders are the most common cause of a slow small business site we see, and the fix is structural.
Spot it: response headers show no cache-control, and the server takes over 600 milliseconds to answer. Fix it: set long cache lifetimes for images, fonts, CSS and JS with versioned filenames, and cache whole pages on the server so PHP is not rebuilding the same page for every visitor. Worth: the second page a visitor opens becomes nearly instant.
Spot it: time to first byte over 800 milliseconds even for a cached page. Fix it: a host with an Indian data centre and current PHP. Shared hosting runs 3,000 to 15,000 a year, and the top of that range buys a server that is not overloaded. Worth: every single request gets faster, which is why we do it before fine tuning.
Spot it: four font families, each in three weights, loaded from a font service. Fix it: two families at most, subset to the characters you use, served from your own domain, with font-display set to swap so text shows in a fallback while the font arrives. Worth: text appears earlier and the page stops flashing invisible.
Spot it: chat widget, analytics, ad pixels, a review badge, a maps embed, all loading before the page is usable. Fix it: remove the ones nobody looks at, load the chat widget only after the visitor scrolls or taps, and put the map behind a static image that loads the real embed on click. Worth: often more than a second on mobile.
Spot it: http goes to https, then to www, then to a trailing slash, three hops before the page. Fix it: one rule that sends any variant straight to the final address in one redirect. Worth: each hop is a full round trip on a phone, and CDNs put a limit on how many they will follow.
Spot it: every image on a long page downloads at once. Fix it: add loading="lazy" to images below the first screen. Then check that the main hero image does not have it, because lazy loading the LCP image makes it appear later, not sooner. Worth: less data on first load and a faster first screen.
Spot it: response headers show no content-encoding, or the connection is HTTP/1.1. Fix it: enable Brotli or gzip on the server and make sure HTTPS is served over HTTP/2 so many files travel over one connection. Worth: text files shrink by around two thirds, and this is a server setting, not a code change.
Spot it: the hero image and main font are discovered late, after the CSS has been parsed. Fix it: a preload link for the LCP image and the one font the headline uses, and a preconnect for any domain you truly must load from. Worth: the last few hundred milliseconds off LCP once everything else is done.
Not a different tool, but a different setup. Choose an Indian test location when the tool offers one, throttle to a 4G profile rather than fast broadband, and use a mid range Android profile rather than a flagship, because that is what most of your visitors carry. Then look at the field data in Search Console's Core Web Vitals report, which is your actual visitors on their actual phones and is the only number that counts for Google.
Two things people miss. Test the pages visitors land on from search and ads, not the home page alone. And test after every change to the site, because a new plugin or a new hero video can undo a month of work in an afternoon.
Measure first. Then images, because they are the biggest and easiest. Then JavaScript and the page builder, because they block interaction. Then hosting and caching, which speed up everything at once. Then fonts, third party scripts and redirects. Then measure again on the same phone on the same connection.
If the site is built on a page builder and every one of the twelve applies, it is often cheaper to rebuild it properly than to patch it, and our development service page describes how we build with responsive images and Core Web Vitals measured on a throttled connection before launch. Speed also feeds the SEO work, which is why article 20's audit checklist starts with it.
Under 2.5 seconds to the largest element on a phone, in the field data. Under 1.5 seconds on desktop is normal for a well built site. Anything over 4 seconds on mobile is losing visitors before they read a word.
Yes, as one signal among many, through the Core Web Vitals assessment. It rarely moves a page on its own, but a slow site loses the visitors it does earn, which is the bigger cost.
A CDN helps if your visitors are spread across regions or your host is overseas. It does not fix oversized images, a page builder or unused JavaScript, which travel just as far over a CDN.
After every change that touches the front end, and once a month regardless, on a phone over a throttled connection. The Search Console report updates on its own; check it each month with the rest of your SEO numbers.
Sign in with Google to join the conversation. We use it for your display name and nothing else, and your email address is never shown.
No comments yet. Sign in above to write the first one.