You open a website.
A blank screen appears.
You wait.
Then finally, the page loads.
But what actually happened during those few seconds?
Why does one website feel almost instant while another feels painfully slow?
It isn't just about writing “better code.”
Website performance is the result of many things working together:
DNS + networking + servers + HTML + CSS + JavaScript + images + caching + browser rendering
And most performance problems come down to two simple questions:
What is the browser waiting for?
What is the browser doing unnecessarily?
Let's break it down.
What Actually Happens When You Open a Website?
Suppose you enter:
https://example.com
Your browser has quite a journey ahead.
A simplified version looks like this:
URL
↓
DNS Lookup
↓
Connect to Server
↓
HTTP Request
↓
Receive Response
↓
Parse HTML
↓
Download CSS / JS / Images
↓
Build DOM + CSSOM
↓
Layout
↓
Paint
↓
Interactive Page
Every step takes time.
So the goal of performance optimization isn't simply:
“Make the code faster.”
It's:
Reduce unnecessary waiting and unnecessary work.
1. Send Less Data
Imagine your homepage downloads:
HTML 250 KB
CSS 400 KB
JavaScript 4 MB
Images 8 MB
Fonts 2 MB
That's a lot of data just to display a page.
Now imagine:
HTML 80 KB
CSS 100 KB
JavaScript 500 KB
Images 1 MB
Fonts 300 KB
The browser has significantly less to download and process.
This is why techniques such as:
- Compression
- Code splitting
- Lazy loading
- Responsive images
- Removing unused dependencies
can have a huge impact.
A simple rule:
If the user doesn't need it yet, don't make them download it yet.
2. Images Can Be Your Biggest Bottleneck
You can optimize your JavaScript perfectly...
…and still have a slow website because of images.
Consider a:
5 MB hero image
That's potentially more expensive than many of your JavaScript files combined.
Instead of sending a huge original image:
<img src="hero-original.jpg" />
serve an appropriately sized and compressed image.
Modern formats such as:
WebP
AVIF
can reduce image size significantly.
For content below the initial viewport, lazy loading can help:
<img
src="feature.webp"
loading="lazy"
alt="Feature"
/>
But don't blindly lazy-load everything.
If the image is part of the initial viewport, delaying it can actually make the page feel slower.
The goal isn't:
“Lazy-load everything.”
It's:
Load the right resources at the right time.
3. JavaScript Has a Cost
One of the biggest misconceptions is:
“If the JavaScript file is only 2 MB, the browser only has to download 2 MB.”
Not quite.
The browser may need to:
Download
↓
Parse
↓
Compile
↓
Execute
↓
Update the page
↓
Render
So JavaScript costs both network bandwidth and CPU time.
This matters especially on slower mobile devices.
That's why removing an unnecessary dependency can sometimes improve performance more than optimizing a tiny function.
4. Don't Ship Code the User Doesn't Need
Imagine your application contains:
Dashboard
Editor
Analytics
Settings
Admin Panel
A user opening the dashboard probably doesn't need all of that JavaScript immediately.
Instead:
Initial Load
↓
Dashboard
↓
User opens Editor
↓
Load Editor Code
This is the idea behind code splitting.
For example:
const Editor = await import("./Editor");
The application can load functionality when it's actually needed instead of sending everything upfront.
This can dramatically reduce the initial JavaScript payload.
5. CSS Is Part of the Rendering Process
CSS isn't just decoration.
The browser uses HTML and CSS to determine what should appear on the screen.
A simplified rendering pipeline looks like:
HTML
↓
DOM
CSS
↓
CSSOM
DOM + CSSOM
↓
Render Tree
↓
Layout
↓
Paint
Large stylesheets and unnecessary CSS can increase the amount of work the browser has to perform.
So:
Less unnecessary CSS
+
Efficient loading
=
Less browser work
6. Your Backend Can Make a Fast Frontend Slow
Imagine you've optimized everything:
- Tiny JavaScript
- Optimized images
- Minimal CSS
- Good caching
But your API takes:
3 seconds
Your website is still slow.
The request might look like:
Browser
↓
API
↓
Database
↓
API
↓
Browser
If the database query takes 2 seconds, the user is waiting.
Backend performance therefore matters just as much as frontend performance.
Common improvements include:
- Database indexes
- Better queries
- Caching
- Pagination
- Fewer API calls
- Server-side caching
- Avoiding unnecessary database work
A fast frontend can't hide a slow backend.
7. Let the Browser Remember
Why download the same files every time?
Consider:
app.js
styles.css
logo.svg
font.woff2
On the first visit:
Browser → Server
← app.js
On a later visit, the browser may be able to reuse the cached resource.
Browser → Cache
← app.js
That's the basic idea behind browser caching.
Good caching strategies can make repeat visits dramatically faster and reduce unnecessary network requests.
8. Bring Content Closer to Users
Imagine your server is located in the US.
Your user is in India.
The request and response have to travel a long distance.
A CDN can place static content closer to users:
User
↓
CDN Edge
↓
Origin Server
Resources such as:
Images
CSS
JavaScript
Fonts
Videos
can often be served from an edge location closer to the user.
Less network distance can mean lower latency.
9. Load What's Important First
Imagine your homepage needs to show:
Welcome to My App
But before the user sees it, you're loading:
Analytics
Chat widget
Recommendations
Advertisements
Extra JavaScript
Footer images
The user doesn't need all of that immediately.
Prioritize the content that matters first:
Critical Content
↓
Render
↓
User sees something useful
↓
Load non-critical resources
This is one of the key ideas behind optimizing the Critical Rendering Path.
A fast website isn't necessarily one that loads everything quickly.
It's often one that makes the important things appear quickly.
10. Don't Let the Page Jump Around
Imagine you're about to click:
[ BUY NOW ]
Suddenly an image loads above it.
The button moves.
You click.
You hit something else.
Not great.
This is the kind of problem measured by Cumulative Layout Shift (CLS).
One simple technique is to reserve space for images:
<img
src="product.webp"
width="800"
height="600"
alt="Product"
/>
Now the browser knows how much space the image needs before it finishes loading.
Stable layouts create a better experience.
11. Measure Before You Optimize
This is where many developers make a mistake.
They see a slow website and immediately start changing code.
Instead:
Measure
↓
Find the bottleneck
↓
Fix it
↓
Measure again
Tools such as Chrome DevTools and Lighthouse can help you investigate:
Network
Performance
Coverage
Lighthouse
Look for:
🐌 Slow requests
📦 Huge resources
🟨 Long JavaScript tasks
📜 Unused code
🎨 Rendering bottlenecks
📐 Layout shifts
Don't optimize what looks slow.
Optimize what the measurements show is actually slow.
What About Core Web Vitals?
Performance isn't just about how quickly a page technically loads.
It's also about how the experience feels to the user.
Three important Core Web Vitals are:
LCP — Largest Contentful Paint
Measures how quickly the main content becomes visible.
A good target is:
≤ 2.5 seconds
INP — Interaction to Next Paint
Measures how responsive the page feels when users interact with it.
A good target is:
< 200 ms
CLS — Cumulative Layout Shift
Measures unexpected movement of content while the page loads.
For CLS:
Lower is better.
These metrics aren't the entire story, but they're useful signals when evaluating real-world user experience.
The Mental Model I Use
You don't need to memorize dozens of optimization tricks.
Think about performance in two categories:
1. Waiting
DNS
↓
Network
↓
Server
↓
API
↓
Database
2. Working
Parse HTML
↓
Parse CSS
↓
Execute JavaScript
↓
Calculate Layout
↓
Paint
↓
Handle Interactions
So:
FAST WEBSITE
│
┌───────┴───────┐
↓ ↓
WAIT LESS DO LESS
│ │
↓ ↓
Faster APIs Less JavaScript
CDN Smaller images
Caching Less CSS
Compression Less rendering
That's the real performance strategy.
A Practical Performance Checklist
Before calling your website “fast”, ask:
□ Are my images optimized?
□ Am I shipping unnecessary JavaScript?
□ Can I split my code?
□ Am I loading non-critical resources later?
□ Are static assets cached?
□ Is my API fast?
□ Are database queries efficient?
□ Can a CDN reduce latency?
□ Am I preventing layout shifts?
□ Have I tested on slower devices?
□ Have I measured before and after?
The Biggest Lesson
A fast website isn't created by one magic trick.
It's created by removing unnecessary work and reducing unnecessary waiting.
Think of the process like this:
Send less
↓
Download less
↓
Parse less
↓
Execute less
↓
Render less
↓
Wait less
↓
⚡ Better Experience
So the next time someone asks:
“How do I make my website faster?”
Don't immediately answer:
“Use caching.”
or:
“Optimize your images.”
Instead ask:
“What is the browser spending time waiting for or doing unnecessarily?”
Find the bottleneck.
Fix it.
Measure again.
Repeat.
That's how websites actually become fast.
Top comments (0)