How We Cut Page Load Time by 70%: A Speed Audit Walkthrough

The short answer

A website speed audit works when you measure first, fix the biggest bottlenecks second, and measure again under the same conditions. In the walkthrough below, that sequence cut the selected page load time measurement by 70% — calculated as (before − after) / before × 100. A measurement falling from 5.0 seconds to 1.5 seconds, for example, is a 70% reduction in that one measurement.

That number is not a promise for every website, nor a 70% improvement in every Core Web Vital or a guaranteed rise in sales. It is the result of fixing several bottlenecks together, in order, and proving each fix with a repeat test. This article shows how we do that at aimEncoders, so you can run the same audit yourself — or judge whether an agency's speed claim is backed by evidence.

Why website speed matters for a small business

A slow page is the moment a visitor decides whether to stay or leave. If the headline, main image, or contact button takes too long to appear, many visitors will try a competitor instead. A page that loads quickly but jumps around as images arrive still feels broken, so an audit must look at both speed and stability.

Mobile deserves special attention. For many Pakistani small businesses, most visitors arrive on a phone, often over mobile data rather than broadband. A site that feels fast on an office desktop can feel very different on a mid-range phone, which is why we test mobile first in most audits and never judge a site by a single desktop score.

One definition matters throughout: when we say "page load time" here, we mean the selected time measurement chosen at the start of the audit and repeated at the end — the same URL, device profile, and test conditions. Without that discipline, before-and-after numbers mean very little.

Step 1: Establish the performance baseline

Every audit starts with measurement, not changes. We run PageSpeed Insights and Lighthouse on the key pages — usually the homepage and the highest-traffic landing or product page — and record the results before touching any code.

We record Largest Contentful Paint (LCP), the point when the main content becomes visible, with a good target of 2.5 seconds or less; Interaction to Next Paint (INP), reflecting responsiveness, with a good target of 200 milliseconds or less; and Cumulative Layout Shift (CLS), measuring visual stability, with a good target of 0.1 or less. We also record Time to First Byte (TTFB), total page weight, request count, JavaScript transfer size, and image payload.

Lab data and real-user data must be kept separate. Lab tests like Lighthouse give a controlled diagnosis, so changes can be compared fairly. Field data, where available, shows what real visitors actually experience. Lab data helps you fix things; field data tells you whether visitors felt the fix. Save the reports and test settings — if you cannot reproduce your baseline, you cannot prove your improvement.

Step 2: Find the biggest bottlenecks

With a baseline in hand, we read the waterfall: the sequence of requests the browser makes, and how long each one takes. In most slow sites, a small number of culprits explain most of the delay, and our job is to find them in order of impact.

First, oversized images and media — a homepage hero image saved at full camera resolution, then displayed at a fraction of that size on a phone. Second, render-blocking CSS and JavaScript, which force the browser to download and process large files before showing anything. Third, server response time and cache behaviour: if the server is slow to answer, or static files are downloaded again on every visit, no front-end tidying will fully fix the experience.

We rank findings by impact and effort, because a founder's budget is finite and the first three fixes usually deliver most of the gain.

Step 3: Optimise images and above-the-fold content

Images are usually the largest single win. The goal is simple: send the smallest image that still looks good at the size it is actually displayed. We resize images to match their display dimensions, serve responsive variants so a phone receives a smaller file than a desktop, use modern formats such as WebP or AVIF where suitable, and compress at a quality level that survives a visual comparison.

We lazy-load images below the fold, but never the main LCP image — lazy-loading the hero delays exactly the content visitors are waiting for. We also set image dimensions in advance, so the layout does not jump when images arrive, protecting the CLS score.

Consider an illustrative example, not a named client case: a homepage downloads a large hero image even though the phone display is much smaller. Check the image dimensions, file size, LCP element, and waterfall, then serve responsive, compressed variants and prioritise the primary visible image. The evidence is the before-and-after image size and LCP, plus a visual-quality check.

Step 4: Improve caching and JavaScript delivery

Caching answers a simple question: why download the same file twice? We inspect headers such as Cache-Control, set long-lived caching for versioned static assets, and keep shorter lifetimes for HTML and frequently updated content. We check whether a CDN cache is hitting or missing, and whether updates invalidate correctly — stale content served fast is still a bug. Cold- and warm-cache visits are tested separately.

JavaScript needs the same discipline. We inspect bundle sizes, remove unused packages and redundant libraries, apply route-level or component-level code splitting where the framework supports it, and defer non-critical scripts. The goal is not simply fewer scripts; it is loading the code needed for the current page, at the right time.

After each change, we re-test that navigation, forms, and analytics still work. A smaller bundle that breaks a contact form is not an optimisation. This is where our website testing and QA process matters: every performance change goes through the same regression checks as any other release, so speed never comes at the cost of a broken page.

Step 5: Fix fonts, hosting, and CDN bottlenecks

Fonts are a quieter bottleneck. Each family, weight, and style is another download, and a page loading six weights it barely uses pays for all of them. We audit which weights are actually used, remove the rest, prefer efficient WOFF2 files, and use font-display: swap so text appears promptly while fonts load. We preload only fonts critical to the initial view, and choose fallback fonts with similar metrics to reduce layout shift.

Hosting comes next. We measure TTFB, review backend processing and caching where delays are evident, and enable compression such as Brotli or gzip. A CDN is evaluated only where it solves a real problem — distance, asset delivery, or cacheable traffic — and we check hit rates to confirm it helps. A more expensive hosting plan is not an automatic speed upgrade; it must address a diagnosed bottleneck.

Step 6: Re-run the audit and validate the result

This is the step most often skipped, and the one that makes the audit honest. We repeat the baseline tests under identical conditions, run several trials, and compare the median — not the single best run.

We record before-and-after LCP, INP, CLS, TTFB, total transferred bytes, and request count, check for regressions, and document the changes that did not help, not only the ones that did. Field data is checked later, once enough real-user data has accumulated. Only then can a percentage be stated honestly: the 70% in this walkthrough's title refers to the reduction in the selected load-time measurement between matched before-and-after tests — not to every metric, and not to business outcomes.

What the speed improvements mean for a small business

Faster pages are easier to use, and easier-to-use pages give visitors fewer reasons to leave. That is the honest claim. They do not guarantee a rise in enquiries or sales, because price, offer, trust, and competition all matter, and we never promise a conversion lift from a speed fix alone.

What a business owner can take from this audit is a method: measure, rank by impact, fix the biggest bottleneck, re-test, and repeat. Even without hiring anyone, the checklist below will tell you whether your site's problem is images, JavaScript, caching, hosting — or something else. And if you do hire help, ask for the before-and-after reports, the test conditions, and the metric behind the headline percentage. A credible agency will have all three ready. Google's Core Web Vitals guidance at https://web.dev/vitals/ sets out the thresholds and the lab-versus-field distinction used here.

A practical website speed audit checklist

Run PageSpeed Insights and Lighthouse on mobile and desktop, and save the reports.

Record LCP, INP, CLS, TTFB, page weight, request count, and JavaScript and image payloads.

Check field data separately from lab data, where field data is available.

Inspect the network waterfall and rank bottlenecks by impact and effort.

Resize and compress images; serve responsive variants; never lazy-load the LCP image.

Set image dimensions to prevent layout shift.

Configure browser and server caching for static assets; test cold and warm visits.

Remove unused JavaScript, split bundles by route, and defer non-critical scripts.

Audit font families and weights; keep only what is used; use WOFF2 and font-display: swap.

Check TTFB, compression, and CDN behaviour; fix only diagnosed delivery bottlenecks.

Re-test under identical conditions, compare medians, and check for regressions.

Document what helped, what did not, and what remains.

Frequently asked questions

What is a website speed audit? A structured measurement of how fast a site loads and responds, followed by a ranked list of the bottlenecks causing the delay — images, JavaScript, caching, fonts, or hosting — and a re-test after fixes to prove what improved.

Do I need a new website to make it faster? Usually not. Most speed gains come from optimising what already exists: images, caching, JavaScript delivery, and hosting configuration. A rebuild is worth considering only when the underlying platform itself is the bottleneck.

Can every website cut load time by 70%? No. The size of the improvement depends on how slow the starting point was and which bottlenecks exist. A site that is already well optimised has less room to improve, and any honest percentage must name the metric and the test conditions behind it.

About the author

Muhammad Asad Ullah is the founder of aimEncoders, a web development agency building custom websites, web applications, and e-commerce stores for small businesses. His team runs a full QA and performance check — including Core Web Vitals and page speed audits — before every launch. If your website feels slow, aimEncoders can run the audit above on your site and show you the ranked fixes, with the numbers to back them up