How to Get Your Website Under 2 Seconds (The Checklist We Actually Use)
Most performance guides are written by people who've never shipped a real site under pressure. This one isn't. Here's the exact sequence of changes — ordered strictly by impact — that consistently gets sites under 2 seconds.
There are roughly a million blog posts about website performance. Most tell you to "compress your images" and "use a CDN" as if these are revelations. This guide is different. It runs through a real checklist — ordered strictly by impact per unit of effort — the one we use when a client site is embarrassingly slow.
Start at the top. Don't skip ahead. The order matters because fixing TTFB alone can take a 4-second site to under 2 seconds before you touch a single image.
Step 1: Get a Baseline First
Never optimise without data. The two numbers that matter most are TTFB (Time to First Byte — server speed) and LCP (Largest Contentful Paint — when the main content appears on screen). If your TTFB is over 800ms, no amount of frontend work will get you under 2 seconds. Fix the server first.
⚡ Website Speed Tester
Measure your current load time and get an actionable breakdown.
Step 2: Fix TTFB (This Is Almost Always the Biggest Win)
Enable full-page caching. For WordPress: WP Rocket, LiteSpeed Cache, or W3 Total Cache. Cached pages skip PHP execution and database queries entirely — TTFB drops from 500ms to under 50ms for cached responses. This single change is worth more than all frontend optimisations combined on a typical CMS site.
Upgrade your hosting if needed. Shared hosting on a loaded server routinely produces TTFB of 1–3 seconds before a single byte reaches the browser. A proper VPS or managed cloud host can cut that by 80% without a single code change.
Fix slow database queries. Enable query logging and look for anything over 100ms. Add indexes to columns used in WHERE clauses, ORDER BY, and JOIN conditions on large tables.
⏱️ TTFB Speed Tester
Isolate server response time separately from the rest of your page load.
Step 3: Add a CDN
A CDN serves static assets from edge nodes near your visitors. A visitor in Sydney connecting to a server in Virginia waits ~200ms in pure network latency before anything loads. A CDN edge in Sydney eliminates that. For international audiences, adding a CDN alone can cut 40–60% off load times. Cloudflare's free tier is excellent. Bunny CDN is outstanding value for higher traffic.
Step 4: Optimise Images (The High-Impact Version)
- Convert to WebP or AVIF. A 200KB JPEG becomes ~120KB in WebP and ~80KB in AVIF with no visible quality loss. This is the single biggest image win available.
- Size images for their container. Don't serve a 2400×1600 image in a 400×300 slot. Resize before uploading, or use
srcsetto serve appropriate sizes per breakpoint. - Lazy-load below-the-fold images. Add
loading="lazy"to any<img>not in the initial viewport. - Preload your LCP image. Add
<link rel="preload" as="image" href="hero.webp">in<head>.
Step 5: Eliminate Render-Blocking Resources
Every CSS and JS file in your <head> blocks rendering until it's downloaded and parsed. Inline critical above-the-fold CSS directly in <head> and load the full stylesheet asynchronously. Add defer to all non-critical scripts.
defer to every non-essential <script> tag in <head> often shaves 200–400ms off Total Blocking Time with literally no other changes.Step 6: Enable Compression and Cache Headers
Enable gzip or Brotli. Text-based resources compress 60–80%. A 200KB JS bundle becomes 40–60KB over the wire. Set Cache-Control: max-age=31536000, immutable on CSS, JS, images, and fonts. Use versioned filenames to bust the cache on deployment. These two things together dramatically reduce repeat-visitor load times.
Speed is not a feature. Speed is the prerequisite for every other feature to matter.