BreadthPerformance10 minutes, with a near-certain drilldown on mobile

Reducing Page Load Time

“How would you reduce the load time of a page?”

What the interviewer is really assessing

This looks like a front-end question and is really a question about method. Almost every candidate can list optimisations; far fewer start by asking what is actually slow, and the difference is the whole assessment. A page can be slow because the server takes a long time to respond, because too many bytes are downloaded, because the download happens over too many round trips, or because the browser cannot render until something blocking finishes — and those four causes have entirely different fixes. Opening with 'I would measure first, because the fix depends on which of these it is' and then showing you know the fixes for each is a much stronger answer than an unordered list, however long the list.

The thirty-second answer

Measure before optimising, because the four causes of a slow page have different remedies: a slow server response, too many bytes, too many round trips, or render-blocking resources. The largest wins in practice are usually serving static assets from a content delivery network close to the user, compressing everything including images in modern formats, eliminating render-blocking CSS and JavaScript, setting explicit dimensions on images so the layout does not shift, and caching aggressively at every layer. On mobile, network latency and processing power dominate, so reducing the number of round trips and the amount of JavaScript matters more than reducing total bytes.

Say this first, then expand into the areas below as the interviewer steers.

What to cover

Measure before optimising

Baseline

Cover this or you fail the question

Separate time to first byte, which is a server and network problem, from the time to render, which is a front-end problem. Optimising the wrong one is the most common wasted effort in this area.
Use the metrics that describe what a user experiences rather than a single load number: when the main content becomes visible, when the page becomes responsive to input, and how much the layout moves while loading.
Distinguish laboratory measurements from real user data. A test from a fast connection on a developer machine systematically hides the problems that most users have, and real-world data is usually the reason a page that 'tests fine' still feels slow.

Common trap: Jumping straight to a fix. If the page takes two seconds to return the first byte, minifying JavaScript changes nothing, and the interviewer will usually have engineered the scenario so that this is true.

Reduce the bytes

Baseline

Cover this or you fail the question

Compress text responses. Gzip is universally supported; Brotli compresses meaningfully better and is worth naming as the current default for anything not needing ancient client support.
Images are almost always the largest payload, so this is where the biggest single win usually is: serve modern formats, size them to the display dimensions rather than shipping originals scaled down in the browser, and use responsive sources so a phone does not download a desktop image.
Ship less JavaScript. Splitting the bundle so a page loads only the code it needs, and removing unused code, is more effective than minifying what should not have been sent.
Minify CSS, JavaScript and markup. Worth doing and worth being honest about: after compression the additional saving is modest, and it is not where a slow page is rescued.

Reduce the round trips

Baseline

Cover this or you fail the question

A content delivery network is the highest-leverage change available for most sites, because it addresses distance directly — no server optimisation removes the round-trip time to a user on another continent.
Cache with long lifetimes and content-hashed filenames, so assets can be cached effectively forever and a deploy invalidates them by changing the name rather than by shortening the lifetime.
HTTP/2 multiplexes many requests over one connection, which removes the head-of-line blocking that made bundling and image sprites necessary under HTTP/1.1. It is worth knowing that this makes some older optimisation advice obsolete rather than merely unnecessary.
HTTP/3 goes further by removing transport-level head-of-line blocking, which matters most on lossy connections — that is, on mobile.

Stop blocking the render

Strong

What separates a solid answer

Stylesheets block rendering by design, because the browser will not paint content it may have to restyle. Inlining the small amount of CSS needed for the top of the page and loading the rest asynchronously is what removes that block.
Scripts block parsing unless marked otherwise. Marking a script deferred lets it download in parallel and execute after parsing; marking it async lets it execute as soon as it arrives, which suits independent scripts such as analytics.
Fonts commonly cause invisible text while loading. Telling the browser to show a fallback immediately and swap when the font arrives is a one-line change with a large perceived effect.
Set explicit width and height on images and reserve space for anything injected later. This does not make the page faster, it stops content jumping as things arrive, which users experience as slowness and which is measured directly by layout-shift metrics.
Third-party scripts are frequently the real problem and are the hardest to fix politically rather than technically. Being able to say that a tag manager loading six vendors is worth more than any bundle optimisation is a sign of experience.

Fix a slow server response

Strong

What separates a solid answer

If time to first byte is the problem, the page is a back-end question: slow database queries, an N+1 query pattern, an uncached expensive computation, or a slow upstream call in the request path.
Cache the rendered output where the content allows it. A page identical for every anonymous visitor can be cached at the edge and never reach the application, which is a step change rather than an improvement.
Prefer serving something immediately over serving everything at once: send the document early and stream the rest, so the browser can begin fetching assets while the server is still assembling the page.

Load only what is needed now

Strong

What separates a solid answer

Lazy-load images and components below the fold so the initial load carries only what the user can see.
Preload the few resources known to be needed and discovered late — typically a font or a hero image — and preconnect to third-party origins so connection setup overlaps with other work.
Prefetch the next likely navigation during idle time, which makes the following page feel instant. Worth pairing with the honest caveat that speculative fetching spends the user's data and battery, so it should be selective rather than applied to every link.

Choosing a rendering strategy

Senior

The senior signal

A single-page application is not automatically faster and often is not. It improves subsequent navigations while making the first load worse, because a large bundle must download and execute before anything renders — so it is a trade rather than an optimisation, and claiming otherwise is a common way to lose credit on this question.
Server-side rendering or static generation gets content on screen without waiting for JavaScript, which matters most for first visits and for search and AI crawlers.
Static generation with a content delivery network is the fastest arrangement available for content that does not need to be personalised per request, and it is worth asking whether the personalisation actually required is small enough to add on the client afterwards.
The senior instinct here is that architecture decides the ceiling. A page whose content requires several sequential client-side requests before anything appears cannot be tuned into a fast page, and recognising when the fix is structural rather than incremental is the distinguishing judgement.

Drilldowns to expect

How does your answer change for mobile?Medium

The constraints reorder, and the reordering is the point. Latency dominates over bandwidth: a mobile connection may have acceptable throughput while every round trip costs a great deal, so reducing the number of sequential requests matters more than reducing total bytes. Radio behaviour matters too, since bringing the radio up has both a latency and a battery cost, which favours fewer, larger transfers over many small ones. Processing power is the constraint most often forgotten — a mid-range phone parses and executes JavaScript several times slower than a development laptop, so a bundle that is merely large on desktop can dominate the load on mobile, and shipping less JavaScript is more valuable than compressing what is sent. Connections are also variable rather than simply slow, which is where HTTP/3 helps, because packet loss on one stream stops blocking the others. Images need genuine attention: serve sizes matched to the device rather than relying on the browser to scale down something much larger. And test on a real mid-range device on a real network, because emulated throttling reproduces the network and not the processor. Worth closing with the point that these are the same techniques weighted differently rather than a separate playbook, and that optimising for the mobile case generally improves the desktop case as well.

The page scores well in synthetic tests but users still say it is slow. What is going on?Hard

Synthetic tests measure a specific machine on a specific connection loading a page cold, and real users differ on every one of those dimensions. Start by getting field data segmented by device class, connection type, geography and whether the visit is a first or repeat one, because the aggregate almost always hides the affected group. Several explanations are common. The test may run from a location close to your infrastructure while a large share of users are far away, which no server-side change addresses. The test may load the page anonymously while the real complaint is from logged-in users whose personalised page bypasses every cache. The measured metrics may genuinely be fine while the page feels slow for reasons those metrics do not capture — an interface that renders quickly but does not respond to taps for another second, or content that shifts as late elements arrive. Interaction latency after load is the most commonly missed cause, since it is invisible to a test that stops measuring once loading finishes. There may also be a specific slow path rather than a slow page: one endpoint that is slow only for users with a lot of data, which is a tail problem that averages conceal entirely. The method that resolves it is to stop looking at averages and look at the distribution — the slowest ten percent of real sessions, segmented — and to ask the complaining users what they were doing, because they are usually describing a specific action rather than the initial load.

Comes up in these roles

Solutions Architect
Cloud Architect
Cloud Engineer
Site Reliability Engineer
Software Engineer

Reducing Page Load Time

What the interviewer is really assessing

The thirty-second answer

What to cover

Measure before optimising

Reduce the bytes

Reduce the round trips

Stop blocking the render

Fix a slow server response

Load only what is needed now

Choosing a rendering strategy

Drilldowns to expect

Comes up in these roles

Concepts used above

Apply it to a design

Read next

Reducing Page Load Time

What the interviewer is really assessing

The thirty-second answer

What to cover

Measure before optimising

Reduce the bytes

Reduce the round trips

Stop blocking the render

Fix a slow server response

Load only what is needed now

Choosing a rendering strategy

Drilldowns to expect

Comes up in these roles

Concepts used above

Apply it to a design

Read next