Google has made it unambiguous: speed is a ranking factor. And the numbers speak for themselves -- 53% of mobile users leave a page that takes longer than 3 seconds to load. At 5 seconds, the bounce rate climbs to 90%. Every second of load time reportedly costs Amazon an estimated $1.6 billion in annual revenue.
Yet the median load time for mobile websites in early 2026 sits at 8.6 seconds. The gap between what users expect and what most websites deliver is enormous -- and that is precisely where the opportunity lies.
This guide shows you the most impactful optimizations, sorted by impact. No theory, just concrete measures with measurable results.
Understanding Core Web Vitals
Before we optimize, we need to know what we are measuring. Google's Core Web Vitals consist of three metrics:
- LCP (Largest Contentful Paint) -- When does the largest visible element load? Target: under 2.5 seconds.
- INP (Interaction to Next Paint) -- How quickly does the page respond to interactions? Target: under 200 milliseconds.
- CLS (Cumulative Layout Shift) -- How stable is the layout during loading? Target: under 0.1.
Important: Google measures these values in the field (real user data from Chrome), not in the lab. Lighthouse scores are an indicator, but field data counts for rankings.
Image Optimization: The Biggest Lever
Images account for an average of 50-65% of a website's page weight. This is by far the biggest optimization lever.
Modern Formats: WebP and AVIF
| Format | Quality | Size vs. JPEG | Browser Support 2026 |
|---|---|---|---|
| JPEG | Baseline | 100% | 100% |
| WebP | Equivalent | 25-35% smaller | 97% |
| AVIF | Equivalent | 40-50% smaller | 93% |
Recommendation: Use AVIF as the primary format with WebP as fallback:
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="Hero Image" width="1200" height="600" loading="lazy">
</picture>
Responsive Images
Do not deliver a 2400px image to a 375px smartphone. Use srcset and sizes:
<img
srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw"
src="hero-800.webp"
alt="Hero"
loading="lazy"
decoding="async"
>
Lazy Loading Done Right
Only lazy-load images below the visible area. The hero image and everything above the fold must load immediately:
<!-- Above the fold: NO lazy loading, use preload instead -->
<link rel="preload" as="image" href="hero.avif" type="image/avif">
<img src="hero.avif" alt="Hero" fetchpriority="high">
<!-- Below the fold: lazy loading -->
<img src="team.avif" alt="Team" loading="lazy" decoding="async">
Real-world result: On a client project, consistent image optimization reduced page weight from 4.2 MB to 890 KB. LCP improved from 4.1 to 1.8 seconds.
JavaScript Optimization
JavaScript is the second-biggest performance killer after images. Every kilobyte of JavaScript must be downloaded, parsed, and executed.
Code Splitting
Only load the JavaScript code needed for the current page:
// Instead of loading everything at once:
// import { HeavyComponent } from './heavy-component';
// Load dynamically when needed:
const HeavyComponent = dynamic(() => import('./heavy-component'), {
loading: () => <Skeleton />,
ssr: false
});
Script Loading Strategies
| Attribute | Behavior | When to Use |
|---|---|---|
| (none) | Blocks rendering | Never, unless absolutely critical |
| defer | Loads in parallel, executes after HTML parsing | For your own scripts |
| async | Loads in parallel, executes immediately | For independent third-party scripts |
Audit Third-Party Scripts
Analytics, chat widgets, social media embeds, A/B testing tools -- every script costs performance. Measure the actual value of each script:
- Google Tag Manager: 28-45 KB, plus all tags loaded within
- Intercom Chat: 200-300 KB JavaScript
- Facebook Pixel: 60-80 KB
- Hotjar: 40-60 KB
Rule of thumb: If a third-party script generates less revenue than the performance it costs, remove it.
CSS Optimization
Critical CSS
Extract the CSS needed for the visible area and load it inline in the HTML:
<head>
<style>
/* Only CSS for above-the-fold elements */
.hero { display: flex; min-height: 100vh; }
.nav { position: fixed; top: 0; width: 100%; }
</style>
<link rel="preload" href="/styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
</head>
Remove Unused CSS
Most websites load 60-80% more CSS than actually needed. Tools like PurgeCSS or Chrome DevTools Coverage analysis show which CSS can be removed.
Font Loading Strategies
Web fonts are a common cause of CLS and slow text rendering.
The Optimal Strategy
@font-face {
font-family: 'Inter';
src: url('/fonts/inter-var.woff2') format('woff2');
font-display: swap;
font-weight: 100 900;
}
font-display: swap shows a system font first and swaps it once the web font loads. This prevents invisible text (FOIT).
Variable Fonts drastically reduce the number of font files. Instead of 6 individual files, a single variable font suffices.
Server-Side Rendering and Caching
SSR vs. CSR Performance Comparison
| Metric | Client-Side Rendering | Server-Side Rendering | Improvement |
|---|---|---|---|
| TTFB | 100-200ms | 150-400ms | -50% (worse) |
| FCP | 1.5-3.0s | 0.5-1.2s | +60% (better) |
| LCP | 2.5-5.0s | 1.0-2.0s | +55% (better) |
| TTI | 3.0-6.0s | 1.0-2.5s | +60% (better) |
SSR has slightly higher TTFB, but all user-relevant metrics are significantly better.
Caching Strategy
# Static assets: Long-term cache
Cache-Control: public, max-age=31536000, immutable
# HTML pages: Revalidation
Cache-Control: public, max-age=0, must-revalidate
# API responses: Short cache
Cache-Control: public, max-age=60, s-maxage=300
CDN Configuration
A CDN reduces latency by delivering content from servers near the user.
Typical improvements from CDN:
- TTFB: 40-60% faster
- Global load times: 30-50% faster
- Server load: 60-80% reduced
Performance Budget
Define clear limits:
| Metric | Budget |
|---|---|
| Total page weight | < 1.5 MB |
| JavaScript (compressed) | < 300 KB |
| CSS (compressed) | < 50 KB |
| Images | < 800 KB |
| LCP | < 2.5s |
| INP | < 200ms |
| CLS | < 0.1 |
Conclusion
PageSpeed optimization is not a one-time project but a continuous process. The most impactful levers are image optimization, JavaScript reduction, and efficient caching. Together, these measures can reduce load time by 50-70%.
At StudioMeyer, performance is not an afterthought but an integral part of every project. Our websites consistently achieve Lighthouse scores above 90 -- because we think about optimization from the very first line of code.
