Web Performance

Web performance is the practice of measuring how quickly a page loads, becomes usable, and responds to user input. A frontend engineer should measure the relevant bottleneck first, then optimize the limiting factor, such as JavaScript, network delivery, rendering, or assets.

Web performance covers both loading and interaction. Useful measurements include how quickly meaningful content appears, when the page becomes responsive, and whether interactions are handled promptly rather than blocked by main-thread work.

Start with measurement instead of guessing. Browser performance tools, network traces, and real-user metrics can reveal whether time is being spent downloading resources, parsing and executing JavaScript, calculating styles and layout, painting, or waiting on the server.

JavaScript is a frequent bottleneck because large bundles increase download, parse, compile, and execution work. Techniques such as code splitting, lazy loading, removing unused dependencies, and deferring noncritical work can reduce the amount of JavaScript required during the initial page load.

Network and asset optimization can also have substantial impact. Compressing resources, serving appropriately sized images, caching effectively, using a content delivery network, and prioritizing critical resources can reduce the time needed to obtain important content.

Performance should be evaluated from the user's perspective and across realistic devices and network conditions. An optimization is useful when measurements show that it improves the relevant user-facing metric without causing unacceptable regressions in accessibility, functionality, or maintainability.

Key points

• Measure before optimizing; identify the dominant bottleneck.
• Separate network, asset, JavaScript, rendering, and interaction costs.
• Reduce critical-path work rather than optimizing code that does not affect user experience.
• Use techniques such as code splitting, lazy loading, caching, compression, and responsive images where measurements justify them.
• Validate improvements with representative devices, network conditions, and user-facing metrics.

Interview questions

How would you investigate a slow web page?

I would first reproduce the problem under realistic device and network conditions and collect performance measurements. I would inspect the network waterfall, JavaScript execution, rendering activity, and important user-facing loading metrics. Then I would identify the largest contributor to the delay instead of making unrelated optimizations. After changing the suspected bottleneck, I would measure again to verify the improvement.

Why can a large JavaScript bundle hurt performance?

A large bundle can take longer to transfer over the network and can also require more parsing, compilation, and execution. On slower devices, CPU work can be especially noticeable even after the download completes. I would look for unused dependencies, opportunities for code splitting, and noncritical features that can be loaded later. The goal is to reduce the JavaScript required on the critical path.

What is the difference between optimizing images and optimizing JavaScript?

Image optimization primarily reduces the bytes and decoding work required for visual assets, while JavaScript optimization targets both transfer size and CPU work. For images, I might use appropriate dimensions, modern formats where supported, responsive images, and lazy loading for below-the-fold content. For JavaScript, I might remove unused code, split bundles, and defer noncritical execution. In both cases, I would prioritize resources that affect the critical user experience.

How would you decide whether a performance optimization is successful?

I would establish a baseline using a clearly defined metric and representative test conditions. After the change, I would compare the same metric under equivalent conditions and check for regressions in related behavior. For production systems, real-user measurements can show whether the improvement reaches actual users rather than only improving a local test. I would also consider whether the added complexity is justified by the observed benefit.

Why should frontend engineers care about the critical rendering path?

The critical rendering path is the sequence of work the browser needs to perform before it can present useful content to the user. Resources and tasks that block this path can delay visual feedback even if the total amount of page work is unchanged. Reducing or prioritizing blocking resources can therefore improve perceived loading performance. The exact optimization depends on what the measurements show is blocking useful content.