Website Performance Optimization Checklist for Faster Business Websites

Website speed is not just an engineering metric—it is a direct revenue driver.

According to Google, as page load time increases from 1 second to 3 seconds, the probability of a bounce increases by 32%. Furthermore, Google's Core Web Vitals directly dictate your search rankings in competitive US, European, and Australian markets.

Here is the definitive technical checklist to achieve sub-second page load speeds and a 95+ Google PageSpeed score.

Two honest notes before the checklist, because speed advice is full of false promises. First, 95+ on mobile PageSpeed is not realistic for most business sites with third-party scripts, and pursuing it can waste weeks. A genuinely fast site usually scores 75-90 on mobile and 95+ on desktop, and the number that matters is not the score but the field data — what real visitors actually experienced. Second, speed work has diminishing returns in a specific order. Fixing images, fonts and hosting typically gets you 80% of the improvement for 20% of the effort. Everything after that is specialist work for the last few hundred milliseconds.

The 2026 Core Web Vitals Optimization Checklist

┌─────────────────────────────────────────────────────────────┐
│ 1. INP (Interaction to Next Paint): Target < 200ms          │
│ • Minify and defer non-critical JavaScript execution        │
│ • Break up long CPU tasks with Web Workers / idle callbacks │
│ • Use CSS transforms for animations instead of JS layout    │
├─────────────────────────────────────────────────────────────┤
│ 2. LCP (Largest Contentful Paint): Target < 2.5s            │
│ • Preload hero images using <link rel="preload">            │
│ • Convert all JPG/PNG images to modern AVIF and WebP        │
│ • Enable Brotli compression and HTTP/3 on your web server   │
├─────────────────────────────────────────────────────────────┤
│ 3. CLS (Cumulative Layout Shift): Target < 0.1              │
│ • Explicit width and height attributes on all <img> & <svg> │
│ • Reserve layout space for dynamic banners and embed cards  │
│ • Use font-display: swap with matching fallback font metrics│
└─────────────────────────────────────────────────────────────┘

What each metric actually measures

LCP is how long until the biggest thing on screen has finished loading — usually your hero image or heading. It is dominated by images and server response time.

INP replaced First Input Delay and measures how long the page takes to respond after a visitor taps or clicks. It is dominated by JavaScript: heavy scripts, third-party widgets and long tasks blocking the main thread.

CLS measures how much the layout jumps around while loading. It is almost always caused by images without dimensions, ads or banners injected late, and fonts swapping after first paint.

Check your real numbers in PageSpeed Insights → field data (which comes from real Chrome users) rather than the lab data, which simulates a synthetic visit. If field data is unavailable for your site, you do not have enough traffic for the metric to be statistically meaningful — use lab data with that caveat in mind.

The Fastest Wins, in Order

If you do nothing else, do these five. In our audits they account for the majority of improvement:

Notice that none of these are clever. Speed work rarely is. The largest single cause of a slow site we audit is a hero image uploaded straight from a camera at 4,000 pixels wide and 3 megabytes, displayed at 600 pixels.

Image Optimization

Images are the biggest lever on almost every site.

• Resize to the actual display size. A 1600px-wide image shown at 800px is 4x more data than needed.
• Use modern formats. AVIF is smallest, WebP is widely supported and a safe default, JPEG remains acceptable for photographs. PNG belongs to graphics with transparency, not photos.
• Serve responsive sizes with srcset so phones do not download desktop-resolution files:

<img src="hero-800.webp"
     srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
     sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1600px"
     width="1600" height="900" alt="Dashboard overview" loading="lazy" fetchpriority="high">

Two details in that snippet do most of the work. The width and height attributes reserve space so the layout does not jump. And fetchpriority="high" on the hero image — while everything below the fold is lazy-loaded — tells the browser what actually matters.

Never lazy-load your hero image. It delays the largest element and makes LCP worse, which is the opposite of the intent.

JavaScript and Third-Party Scripts

JavaScript is the second biggest lever, and the hardest to control because much of it arrives from marketing tools.

• Audit your tags. Every analytics platform, chat widget, heatmap, A/B testing tool and ad pixel costs milliseconds. Sites we audit frequently carry six or more, and at least two are abandoned experiments.
• Load non-critical scripts with defer or async, and load chat widgets only on interaction or after a delay.
• Self-host what you can. A third-party domain adds DNS lookup and connection time; some can be bundled or proxied.
• Remove unused libraries. A site importing a full utility library for three functions is shipping hundreds of kilobytes of dead weight.

A useful rule: every third-party script must answer for itself. If nobody can name what a script is doing and what it returns, remove it and see whether anyone notices. They usually do not.

Fonts

Web fonts cause both delay and layout shift.

• Preload the fonts actually used above the fold.
• Use font-display: swap so text appears immediately in a fallback.
• Limit the number of weights. Each weight is a separate file; three is usually plenty.
• Where possible, self-host rather than relying on a third-party font CDN.
• Choose a fallback with similar metrics so the swap does not visibly reflow.

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-var.woff2') format('woff2');
  font-display: swap;
  font-weight: 100 900;
}

A single variable font file covering all weights is often smaller than two static weights.

Server & Backend Performance Checklist

• [ ] Database Query Optimization: Eliminate N+1 queries using Django select_related() and prefetch_related().
• [ ] Redis Caching: Cache expensive database aggregations and public API endpoints in Redis.
• [ ] Edge CDN Caching: Configure Cloudflare edge caching for static assets, fonts, and pre-rendered HTML.
• [ ] Production Asset Bundling: Use Vite or Webpack with tree-shaking to produce production CSS bundles under 20KB.

Three more that matter on dynamic sites:

• [ ] Set cache headers deliberately. Static assets get long max-age values with a content hash in the filename; HTML gets a short TTL or revalidation.
• [ ] Compress responses with Brotli (falling back to gzip), and enable HTTP/2 or HTTP/3.
• [ ] Measure server response time separately. Time to First Byte above 500ms is a backend or hosting problem, not a frontend one, and no amount of image compression will fix it.

If your site is a content site or a business website, edge caching with sensible invalidation usually gives the single largest backend improvement available — often turning a 900ms response into 80ms for visitors who are not the first to arrive.

How to Test Properly

• PageSpeed Insights for both lab and field data, mobile first.
• WebPageTest for detailed waterfall analysis, and for testing from multiple regions — important if your visitors are in the US, EU and Australia and your server is in one of them.
• Chrome DevTools Performance panel for finding long tasks that hurt INP.
• Lighthouse CI in your pipeline, so performance is checked on every deployment rather than once a year.

Test on a mid-range Android phone on a throttled connection, not your laptop on office Wi-Fi. The gap between those two environments is where most "but it's fast for me" conversations come from.

Performance Budgets

A budget turns speed from an opinion into a rule:

Enforce it in CI. A budget nobody checks is a wish, and performance regressions arrive one reasonable-looking addition at a time.

Common Myths

"A CDN fixes a slow site." A CDN speeds up delivery of what you send. If your page ships 6 MB of unoptimized images and 900 KB of JavaScript, a CDN delivers that slowly-but-consistently.

"The score is the goal." PageSpeed is a diagnostic. A 100 score on a page nobody converts on is worthless. Field data and business metrics are the goal.

"Caching solves everything." Caching helps returning visitors and repeat page views. First visits — which is most of your traffic from search and ads — still need to be fast on their own.

"We'll optimize after launch." Almost nobody does. Performance is far cheaper to preserve during a build than to restore afterwards.

Quick Wins You Can Do This Week

1. Resize and re-compress every image above 300 KB.
2. Add width and height attributes to all images.
3. Add loading="lazy" to everything below the fold.
4. Preload your hero image and primary font.
5. Remove any third-party script you cannot justify.
6. Turn on Brotli and HTTP/2 at your host.
7. Move to a CDN if you have not already.
8. Re-test on a real phone.

Most sites see a meaningful improvement from that list alone, and none of it requires a specialist.

When Speed Needs a Deep Fix

Some sites cannot be fixed by configuration. Consider a rebuild or serious refactor when:

• Time to First Byte is consistently above 800ms despite caching.
• The frontend ships a large JavaScript framework for what is essentially a content page.
• Third-party scripts total more than your own code.
• Images are generated at full resolution at upload time with no pipeline.
• The site is built on a platform that does not allow you to control these things.

In those cases the answer is architectural, and patching around it costs more than it saves.

Checklist

• [ ] Real image dimensions served, in WebP or AVIF
• [ ] width/height on every image
• [ ] Hero image preloaded with fetchpriority="high"
• [ ] Everything below the fold lazy-loaded
• [ ] JavaScript deferred, third-party scripts audited and pruned
• [ ] Fonts limited, preloaded, font-display: swap
• [ ] Brotli compression and HTTP/2 or HTTP/3 enabled
• [ ] CDN or edge caching for static assets
• [ ] Database queries reviewed for N+1
• [ ] Performance budget enforced in CI
• [ ] Field data reviewed monthly, not just after launch

Related reading: Core Web Vitals explains the metrics Google actually measures; website maintenance keeps performance from drifting; and SSR vs SPA covers the architectural decision that sets your ceiling. Need an audit and speed boost for your website? Hire KEHEM IT for performance optimization.

Want the numbers rather than the checklist? Send us the URL and we will run the audit and read you the results.