14 Website Speed Optimization Techniques to Load Under 2 Seconds

A website that loads in under 2 seconds converts measurably better than one that takes 4. That is not a theory. Google's own data shows a one-second mobile delay can cut conversions by 20%, and research from Portent puts the drop at 4.42% per additional second.

The problem with most website speed optimization guides is that they stop at "why speed matters." You already know it matters. What you need is a step-by-step list of what to fix and in what order.

This guide covers 14 specific techniques to get your site loading under 2 seconds, each with concrete steps, code examples where relevant, and the expected business impact. Whether you are building a new site or optimizing an existing one, these are the same steps we use at Vezert to improve website performance across every project.

Speed and conversions are closely linked, and the data is clear:

• Amazon found that every 100ms of added latency cost them 1% in sales.
• Walmart saw a 2% conversion increase for every 1 second of load time improvement.
• The Portent study measured an average 4.42% conversion drop per extra second of load time across 20 industries.

Speed also affects SEO directly. Google uses Core Web Vitals (LCP, CLS, INP) as ranking signals. A slow site does not just lose visitors, it loses search visibility too. SEO and website development are no longer separate conversations.

The bottom line: page load time and conversion rate move together. Every technique in this guide is evaluated through that lens, not just technical performance, but what it does for the business.

Before you optimize anything, you need a baseline. These are the tools that give you the clearest picture:

Google PageSpeed Insights (pagespeed.web.dev) provides Core Web Vitals data from real users (field data) and lab tests. This is the single most important tool because it shows what Google actually measures for ranking.

Lighthouse (built into Chrome DevTools, under the Audits tab) runs detailed performance audits with specific recommendations. Open DevTools, go to the Lighthouse panel, and run a mobile performance test.

WebPageTest (webpagetest.org) generates waterfall charts that show exactly where time is spent during page load. Useful for diagnosing specific bottlenecks.

GTmetrix (gtmetrix.com) combines Lighthouse data with a visual timeline and historical tracking.

Key Metrics to Track

• LCP (Largest Contentful Paint): When the main content becomes visible. Target: under 2.5 seconds.
• CLS (Cumulative Layout Shift): How much the page shifts during loading. Target: under 0.1.
• INP (Interaction to Next Paint): How fast the page responds to clicks. Target: under 200ms.
• TTFB (Time to First Byte): How fast the server responds. Target: under 800ms.

Run these tests on both mobile and desktop. Mobile is what Google primarily uses for ranking, and it is where most speed problems surface.

Here is where your numbers should land. If any metric falls in the "Poor" column, that is your highest priority fix.

These techniques are ordered roughly by impact. Start at the top and work down. Each one includes what to do, how to do it, and what it means for your bottom line.

Images are usually the biggest chunk of page weight. On the average web page, they account for over 40% of total bytes according to the HTTP Archive.

The fix is straightforward:

• Convert images to WebP or AVIF format, which are 25-50% smaller than JPEG/PNG at the same quality.
• Serve responsive images using srcset so mobile users do not download desktop-sized files.
• Set explicit width and height attributes to prevent layout shifts (improves CLS).
• Compress aggressively. Most images can lose 40-60% of file size with no visible difference.

<img
  src="/hero.webp"
  srcset="/hero-480.webp 480w, /hero-800.webp 800w, /hero-1200.webp 1200w"
  sizes="(max-width: 800px) 100vw, 1200px"
  width="1200" height="630"
  alt="Product screenshot"
  loading="lazy"
/>

Business impact: Image optimization alone typically reduces page weight by 30-50%, which directly improves LCP and total load time. For landing pages where the hero image is the LCP element, this is often the single biggest win.

When a returning visitor loads your site, the browser cache determines whether assets get re-downloaded or served from local storage. Without proper cache headers, every visit is like the first one.

Set Cache-Control headers on static assets:

# Static assets (images, fonts, JS, CSS)
Cache-Control: public, max-age=31536000, immutable

# HTML pages
Cache-Control: public, max-age=0, must-revalidate

The immutable flag tells browsers not to even check for updates on versioned files. For HTML, use must-revalidate so users always get fresh content while assets stay cached.

If you are on a framework like Next.js (which we use at Vezert), static assets get content-hash filenames by default, making long cache lifetimes safe.

Business impact: Browser caching can make repeat page loads 80% faster. For sites where users visit multiple pages per session, like corporate websites or web portals, this compounds into a noticeably smoother experience.

A content delivery network caches your site on servers around the world so users get served from the closest location. Without a CDN, a visitor in Tokyo makes a round trip to a server in Virginia for every request.

Popular options:

• Vercel Edge Network (built-in with Next.js deployments)
• Cloudflare (free tier covers most sites)
• AWS CloudFront (for custom infrastructure)

A CDN reduces latency by 50-70% for users far from your origin server. It also offloads traffic from your web host, which means better performance under load.

For international sites with users across multiple regions, a CDN is not optional. It is the only way to consistently achieve a website loading speed under 2 seconds for a global audience.

Business impact: CDN deployment typically cuts TTFB by 100-300ms for distant users. If your site serves multiple countries, this is often the difference between a "Good" and "Needs Work" TTFB score.

Minification strips whitespace, comments, and unnecessary characters from your CSS and JavaScript files. It does not change what the code does, just makes the files smaller.

Modern build tools handle this automatically:

• Next.js / Webpack / Vite: minification is on by default in production builds.
• Standalone CSS: use cssnano or lightningcss.
• Standalone JS: terser or esbuild.

If you are not using a build tool, online tools like Minifier.org work for one-off files.

Business impact: Minification typically reduces file sizes by 10-20%. On its own that sounds modest, but combined with compression (technique 8), the effect multiplies. Every kilobyte matters on mobile connections.

Render-blocking CSS and JavaScript prevent the browser from painting anything until they finish downloading and executing. This is one of the most common reasons for a high LCP score.

The fixes:

• Inline critical CSS directly in <head> so the first paint does not wait for an external stylesheet.
• Defer non-critical CSS using media="print" onload="this.media='all'".
• Add async or defer to script tags so JavaScript does not block rendering.

<!-- Defer non-critical CSS -->
<link rel="stylesheet" href="/non-critical.css" media="print" onload="this.media='all'">

<!-- Defer JavaScript -->
<script src="/analytics.js" defer></script>

Lighthouse flags render-blocking resources specifically. Open your audit, look for the "Eliminate render-blocking resources" opportunity, and work through the listed files.

Business impact: Removing render-blocking resources can improve First Contentful Paint by 1-3 seconds, which directly accelerates how fast users see meaningful content. This is critical for high-quality websites that need to make a strong first impression.

Lazy loading defers images and videos that are below the fold until the user scrolls to them. This means the browser only downloads what is immediately visible, cutting initial page weight significantly.

The simplest approach is the native loading="lazy" attribute:

<img src="/team-photo.webp" loading="lazy" width="800" height="600" alt="Team photo" />

Do NOT lazy-load the hero image or any above-the-fold content. Those should load immediately (use loading="eager" or just omit the attribute) because they are usually the LCP element.

For more control, use the Intersection Observer API to trigger loading when elements enter the viewport.

Business impact: Lazy loading typically reduces initial page weight by 30-40%. For content-heavy pages like blogs or portfolio pages, the savings are even larger because most images are below the fold.

TTFB (Time to First Byte) measures how long the server takes to start responding. Everything else, rendering, images, scripts, waits for this. If TTFB is slow, nothing else can compensate.

Common causes and fixes:

• Slow web host: Cheap shared hosting often has TTFB over 1 second. Move to a managed provider or edge deployment (Vercel, Netlify, Cloudflare Pages).
• Unoptimized database queries: Profile slow queries, add indexes, cache frequent reads.
• No server-side caching: Add Redis or Memcached for dynamic content. For static sites, pre-render at build time.
• Missing CDN: See technique 3.

According to web.dev, a TTFB under 800ms is the target. Under 200ms is what you get with static hosting or edge functions.

Business impact: TTFB affects every single page load. Cutting it from 1.5s to 300ms gives you over a second of headroom for everything else, often the difference between loading under 2 seconds or not.

Text-based files (HTML, CSS, JavaScript, JSON, SVG) compress extremely well. Gzip reduces their size by 60-80%. Brotli, the newer alternative, compresses 15-20% better than Gzip.

Most hosting providers and CDNs enable Gzip by default. Brotli requires HTTPS and may need explicit configuration on custom servers.

To verify: open Chrome DevTools, go to the Network tab, and check the Content-Encoding header on your responses. You should see br (Brotli) or gzip.

Business impact: If compression is not enabled, you are serving files 3-5x larger than necessary. This is one of the easiest fixes with the highest payoff, especially for JavaScript-heavy sites.

Each file the browser needs to download, each CSS sheet, each script, each image, is an HTTP request. More requests mean more round trips, more latency, and a longer time before the page is usable.

Steps to reduce requests:

• Combine CSS files where possible (most bundlers do this).
• Inline critical CSS directly in the HTML <head> to eliminate one round trip.
• Use CSS sprites or inline SVGs for small icons instead of separate image files.
• Remove unused CSS and JavaScript. Tools like Chrome DevTools Coverage tab show exactly what code runs and what does not.

Business impact: Going from 80 HTTP requests to 40 can shave 500ms-1s off load time on slower connections. This matters most for mobile users, who still make up the majority of web traffic.

Custom fonts are a common source of invisible text (FOIT) or layout shifts (FOUT). If the font file takes 2 seconds to download, users either see nothing or see a flash of fallback text.

Fix this with:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-var.woff2') format('woff2');
  font-display: swap;
  unicode-range: U+0000-00FF;
}

• font-display: swap shows fallback text immediately, then swaps when the font loads.
• Subset your fonts to only include the characters you actually use (unicode-range).
• Use variable fonts when possible. One file replaces 4-6 weight/style variants.
• Self-host fonts instead of loading from Google Fonts to avoid an extra DNS lookup.

Business impact: Font optimization prevents invisible text during loading and reduces CLS. For brand-heavy corporate sites, this keeps the first impression clean instead of janky.

The browser discovers resources as it parses HTML, which means deeply nested files (fonts referenced in CSS, images in CSS backgrounds) are found late. Preloading tells the browser to start fetching them sooner.

<!-- Preload hero image (the LCP element) -->
<link rel="preload" as="image" href="/hero.webp" type="image/webp">

<!-- Preload critical font -->
<link rel="preload" as="font" href="/fonts/inter-var.woff2" type="font/woff2" crossorigin>

<!-- Preconnect to third-party origins -->
<link rel="preconnect" href="https://fonts.googleapis.com">

Be selective. Preloading too many resources defeats the purpose because everything competes for bandwidth. Preload only the LCP image, the primary font, and any critical third-party connection.

Business impact: Preloading the LCP image alone can improve Largest Contentful Paint by 200-500ms. Combined with preconnecting to third-party origins, this is low-effort, high-return.

Shipping a single massive JavaScript bundle means every user downloads code for pages they may never visit. Code splitting breaks that bundle into smaller chunks loaded on demand.

In frameworks like Next.js and React:

// Dynamic import - only loads when needed
const HeavyComponent = dynamic(() => import('./HeavyComponent'), {
  loading: () => <Skeleton />,
});

Tree-shaking removes unused exports from your bundle at build time. Modern bundlers (Webpack 5, Vite, Turbopack) do this automatically for ES modules, but it breaks with CommonJS require() syntax.

Check your bundle size with tools like @next/bundle-analyzer or source-map-explorer to find the biggest offenders.

Business impact: A well-split application can reduce initial JavaScript payload by 40-60%. Less JavaScript means faster Time to Interactive, which directly affects how quickly users can interact with your site.

Analytics, chat widgets, ad scripts, social embeds: third-party scripts are often the heaviest items on a page, and you have the least control over them.

Steps to manage them:

• Audit everything. Open Chrome DevTools, go to the Network tab, filter by "third-party," and check how much each script costs in size and time.
• Defer non-critical scripts. Analytics and chat widgets do not need to load before the page is usable.
• Use loading="lazy" for embeds (YouTube, maps, social feeds).
• Replace heavy widgets with lighter alternatives. A 300KB chat widget might have a 30KB alternative.
• Set a script budget. If a third-party script adds more than 50ms to load time, question whether it earns its keep.

Business impact: We have seen sites where third-party scripts accounted for 60%+ of total JavaScript. Cleaning these up can cut seconds off load time and dramatically improve INP (interaction responsiveness).

Speed optimization is not a one-time project. New features, content updates, and dependency upgrades can silently degrade performance if nobody is watching.

Set up continuous monitoring:

• Google Search Console tracks real-user Core Web Vitals over time. Check the "Core Web Vitals" report monthly.
• Lighthouse CI (or similar) runs performance tests in your deployment pipeline so regressions get caught before they reach users.
• Real User Monitoring (RUM) tools like Vercel Analytics or web-vitals library capture actual field data from your visitors.

Create a performance budget: define maximum values for page weight, JavaScript size, and LCP that trigger alerts when exceeded.

Business impact: Teams that monitor performance catch regressions 10x faster than those that audit quarterly. Post-launch optimization only works if you have the data to see what changed and when.

Use this as a quick pass/fail check for your site. If you are missing more than a few of these, start with the ones that affect Core Web Vitals first.

Server and Infrastructure

• TTFB is under 800ms across all regions
• A content delivery network (CDN) is serving static assets
• Server response time is stable under traffic spikes
• Gzip or Brotli compression is enabled for text-based files

Images and Media

• All images are in WebP or AVIF format
• Responsive images use srcset for different screen sizes
• Images below the fold use loading="lazy"
• All images have explicit width and height attributes

CSS and JavaScript

• CSS and JS are minified in production
• Critical CSS is inlined in <head>
• JavaScript bundles are code-split by route
• Unused CSS and JS are removed (check with Coverage tab)
• Render-blocking scripts use async or defer

Fonts

• Web fonts use font-display: swap
• Fonts are subsetted to required character ranges
• Primary font is preloaded with <link rel="preload">

Monitoring

• Core Web Vitals are tracked in Google Search Console
• Performance tests run in the CI/CD pipeline
• Third-party scripts are audited quarterly
• Page weight budget is defined and enforced

This checklist covers the same ground as a full website audit. If your site passes all of these, your website's performance is in good shape.

Website speed optimization is not one big fix. It is 14 smaller ones that stack up. Images, caching, CDN, compression, render-blocking resources, fonts, lazy loading, server response, code splitting, and monitoring, each shaves off time, and together they get you under 2 seconds.

Start with your PageSpeed Insights score. Fix whatever it flags first. Work through this list from technique 1 to 14, measuring after each change. You do not need to do everything at once, but you do need to do them.

The business case is simple: faster sites convert better, rank higher, and cost less to serve. Every second you shave off load time is money.

If you want help, Vezert builds speed into every project from the start. We run the same techniques listed here across our website development process, and you can see the results in our portfolio. Speed is not something we fix later. It is how we build.