Skip to main content

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

Andrews Ribeiro

Founder & Engineer

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

Practice checklist

Use this when you answer

You finished this article

Part of the track: Senior Frontend Interview Trail (9/15)

Next article SSR, Hydration, and Client-Side Rendering Without Mixing Them Up Previous article Render Tree, Layout, Paint, and Reflow: What Causes Jank

Keep exploring

Related articles