February 10 2025
How the Browser Loads JS, CSS, Fonts, and Images
How those resources enter the page at different times and with different weights, and why that changes painting, blocking, and perceived speed.
Andrews Ribeiro
Founder & Engineer
4 min Intermediate Frontend
Track
Senior Frontend Interview Trail
Step 9 / 15
The problem
When a page feels slow, many people look only at the total number of requests or the total bytes downloaded.
That helps a little.
But it is still a weak view.
Because the browser does not treat all resources in the same way.
And the user does not feel every delay in the same way either.
A heavy image below the fold is a different problem from:
- delayed critical CSS
- JavaScript blocking the main thread
- a font swapping text after it appears
Mental model
The browser discovers and requests resources while it builds the page.
But each file type interferes with a different phase:
- CSS influences visual rendering
- JavaScript can delay parse, execution, and interactivity
- fonts alter how text appears
- images weigh on bytes, layout, and painting
Instead of asking “is the site heavy?”, it helps to ask:
what is delaying seeing, reading, clicking, or stabilizing the screen?
Breaking the problem down
CSS
CSS looks cheap because “it is not logic.”
But it is often very important for the initial render.
Without the relevant styles, the browser may avoid painting early what it still cannot present correctly.
That is why critical CSS often has strong impact on:
- first paint
- initial layout
- visual stability
JavaScript
JavaScript costs in more than one stage:
- download
- parse
- compilation
- execution
And it still competes for the main thread with:
- input
- layout
- paint
- hydration
That is why a large bundle is not only a network problem.
It is also a CPU problem and an interactivity problem.
Fonts
Fonts look like a visual detail, but they strongly affect perception.
They can cause:
- invisible text for a while
- visual swaps when the final font arrives
- subtle or large layout changes
When text metrics change between the fallback font and the final one, the page can visibly move in front of the user.
Images
Images often cost a lot in bytes.
But the cost does not stop there.
They can also cause:
- expensive painting
- layout shift if dimensions are not well defined
- visual delay in important areas of the page
A hero image is different from a small icon.
Again: not every resource weighs the same.
Simple example
Imagine a homepage with:
- initial HTML
- one main CSS file
- a large JS bundle
- a custom font
- a heavy hero image
If CSS is delayed, the page may delay its useful paint.
If JS is large, the structure may appear, but interactivity will take longer.
If the font swaps late, text can flicker or move.
If the hero image arrives late without clear dimensions, the fold feels unstable.
The user does not feel “a 2 MB page.”
They feel:
- “it took too long to appear”
- “it appeared but I still could not use it”
- “the screen kept moving”
Common mistakes
- Treating every byte as if it had the same weight.
- Looking only at the number of requests.
- Ignoring JavaScript execution cost.
- Assuming images are always the main culprit.
- Forgetting that fonts and CSS change the initial experience a lot.
How a senior thinks about it
People with more experience usually break loading into smaller questions:
- what blocks first paint?
- what blocks interactivity?
- what causes visual instability?
- what can arrive later without hurting the experience?
That decomposition is much more useful than talking vaguely about a “heavy site.”
What the interviewer wants to see
In interviews, this topic appears as a real check of browser and performance understanding.
Your level rises when you:
- distinguish the impact of CSS, JS, fonts, and images
- connect each resource to a phase of the experience
- talk about CPU beyond the network
- avoid simplistic slogans like “just compress everything”
A strong answer often sounds like this:
I would separate what blocks seeing from what blocks interacting. CSS and HTML influence initial reading a lot. JavaScript also costs CPU. Fonts and images affect stability and visual perception.
A slow browser is not always screaming about bytes. Sometimes it is asking for help because things arrived in the wrong order.
Quick summary
What to keep in your head
- CSS, JavaScript, fonts, and images enter the loading path with different impacts on what the user can see and do.
- CSS usually matters more for the first useful render than a late decorative image.
- JavaScript does not cost only download. It also costs parse, execution, and competition for the main thread.
- Understanding the order and effect of each resource helps much more than talking vaguely about a heavy page.
Practice checklist
Use this when you answer
- Can I explain why CSS may delay the first useful paint?
- Do I know why JavaScript costs more than file size alone?
- Can I point out the difference between critical and non-critical resources during loading?
- Can I connect images, fonts, and layout to perceived speed?
You finished this article
Part of the track: Senior Frontend Interview Trail (9/15)
Share this page
Copy the link manually from the field below.