We’ve all said it.
“It loads in about 2 seconds on my machine.”
No stopwatch.
No tooling.
Just vibes.
And somehow, that sentence has shipped more performance assumptions than any metric ever will.
Let’s talk about why humans are terrible at measuring page load time—and what actually helps.
Why Our Brains Are Bad Performance Tools
Humans don’t measure time. We estimate it.
And those estimates are influenced by:
- Cached assets
- Muscle memory
- Expectations
- Coffee intake ☕
A page that feels fast might still:
- Block the main thread for seconds
- Delay rendering
- Do nothing visually while JavaScript works overtime
By the time you say “it loaded,” the browser might still be very busy.
“Loaded” According to… Whom?
Ask three people when a page is “loaded” and you’ll get four answers.
Some common interpretations:
- The spinner disappeared
- The header showed up
- The page stopped jumping
- The button I wanted became clickable
None of these are wrong—but none of them are precise.
Browsers, on the other hand, are painfully precise.
What the Browser Thinks Happened
When you navigate to a page, the browser tracks everything:
- Navigation start
- Response received
- DOM parsing
- Layout
- Paint
- Load events
These aren’t opinions.
They’re timestamps.
The problem isn’t lack of data—it’s how scattered the data is across tools.
Why “It Felt Fast” Isn’t a Metric
Here’s a common dev flow:
- Open page
- Looks fine
- Ship it 🚀
But what you didn’t see:
- A 1.8s script blocking rendering
- Layout shifts after first paint
- A long task right after interaction
Feeling fast ≠ loading fast
And neither guarantees a smooth experience.
The Tool Zoo 🦓
Performance tooling is great—but each tool answers different questions.
Chrome DevTools
Fantastic for:
- Deep dives
- JS execution
- Rendering issues
Lighthouse
Fantastic for:
- Audits
- Best practices
- Comparisons
Not great for:
- Understanding what actually happened during a single navigation
Load Time (chrome extension)
Useful when:
- You want instant visibility
- You care about navigation milestones
- You don’t want to run an audit every time
It doesn’t optimize anything.
It doesn’t score you.
It just shows what happened.
Sometimes that’s exactly what you need.
WebPageTest
Fantastic for:
- Real network conditions
- Filmstrips
- Repeatable lab tests
Not great for:
- “I just reloaded the page and want to see timings”
A Better Question to Ask
Instead of:
“Did the page load fast?”
Try asking:
- When did rendering start?
- Where did time disappear?
- What happened before the page became usable?
Those questions lead to understanding—not guesswork.
Measuring Without Overthinking
Not every check needs:
- Throttling
- Simulated devices
- A 30-page report
Sometimes:
- Reloading the page
- Looking at navigation timing
- Spotting obvious gaps
…is enough to catch real issues early.
That’s how “2 seconds according to me” turns into actual data.
Final Thought
Performance isn’t about winning arguments with numbers.
It’s about seeing clearly.
So the next time someone says:
“It loads in 2 seconds.”
You can smile and reply:
“According to whom?”
👋 Want to Go Deeper?
In future posts, we’ll look at:
- Why pages appear idle while doing a lot
- How timelines tell better stories than scores
- Common myths developers still believe about load time
Until then—measure first. Guess later.
Top comments (1)
Awesome post @javascriptwizzard !
You can improve what you cant measure :). Beautifully captured.
Lighthouse now focuses more on core web vitals which is a plus and Load time extension
now also shows Critical Measures (TTFB, DCL etc).
I am just loving it.