Web performance | MDN

HTML: Markup language
CSS: Styling language
JavaScript: Scripting language
Web APIs: Programming interfaces
Learn web development
Get to know MDN better
Web performance is the objective measurements and the perceived user experience of load time and runtime. Web performance is how long a site takes to load, become interactive and responsive, and how smooth the content is during user interactions. Performance concerns questions like: Is scrolling smooth? Are buttons responsive? Do pop-ups load quickly and animate fluidly? The objective measurements include time to load, frames per second, and time to become interactive, and subjective experience means how long it feels like it takes for content to load.
The longer it takes for a site to respond, the more users will abandon the site. It is important to minimize the loading and response times and add additional features to conceal latency by making the experience as available and interactive as possible, as soon as possible, while asynchronously loading in the longer tail parts of the experience.
There are tools, APIs, and best practices that help us measure and improve web performance. We cover them in the following pages.
The Performance guides are resources that describe how browsers work, what affects performance, and how to measure, optimize, and monitor performance across various aspects of your application.
Performance means efficiency. In the context of Open Web Apps, this document explains in general what performance is, how the browser platform helps improve it, and what tools and processes you can use to test and improve it.
Users want web experiences with content that is fast to load and smooth to interact with. Therefore, a developer should strive to achieve these two goals. To understand how to improve performance and perceived performance, it helps to understand how the browser works.
Latency is the time it takes for a packet of data to travel from source to a destination. In terms of performance optimization, it's important to optimize to reduce causes of latency and to test site performance emulating high latency to optimize for users with slow or unreliable connections.
There are no clear set rules as to what constitutes a slow pace when loading pages, but there are specific guidelines for indicating content will load (1 second), idling (50ms), animating (16.7ms) and responding to user input (50 to 200ms).
DNS-prefetch is an attempt to resolve domain names before resources get requested. This could be a file loaded later or link target a user tries to follow.
Navigation timings are metrics measuring a browser's document navigation events. Resource timings are detailed network timing measurements regarding the loading of an application's resources. Both provide the same read-only properties, but navigation timing measures the main document's timings whereas the resource timing provides the times for all the assets or resources called in by that main document and the resources' requested resources.
Improving your startup performance is often one of the highest value performance optimizations that can be made. Good user experience includes ensuring your app loads quickly. This article provides performance tips and suggestions for both writing new applications and porting applications to the web from other platforms.
The Critical Rendering Path is the sequence of steps the browser goes through to convert the HTML, CSS, and JavaScript into pixels on the screen. Optimizing the critical render path improves render performance. The critical rendering path includes the Document Object Model (DOM), CSS Object Model (CSSOM), render tree and layout.
Lazy loading is a strategy to identify resources as non-blocking (non-critical) and load these only when needed. It's a way to shorten the length of the critical rendering path, which translates into reduced page load times.
Speculative loading refers to the practice of performing navigation actions (such as DNS fetching, fetching resources, or rendering documents) before the associated pages are actually visited, based on predictions as to what pages the user is most likely to visit next.
A performance budget is a limit to prevent regressions. It can apply to a file, a file type, all files loaded on a page, a specific metric (e.g., Time to Interactive), a custom metric (e.g., Time to Hero Element), or a threshold over a period of time.
Synthetic monitoring and real user monitoring (RUM) are two approaches for monitoring and providing insight into web performance. RUM and synthetic monitoring provide for different views of performance and have benefits, good use cases and shortfalls. RUM is generally best suited for understanding long-term trends whereas synthetic monitoring is very well suited to regression testing and mitigating shorter-term performance issues during development. In this article we define and compare these two performance monitoring approaches.
Animations are critical for a pleasurable user experience on many applications. There are many ways to implement web animations, such as CSS transitions/animations or JavaScript-based animations (using requestAnimationFrame()). In this article, we analyze the performance differences between CSS-based and JavaScript-based animation.
Animation on the web can be done via SVG, JavaScript, including <canvas> and WebGL, CSS animation, <video>, animated GIFs and even animated PNGs and other image types. The performance cost of animating a CSS property can vary from one property to another, and animating expensive CSS properties can result in Jank as the browser struggles to hit a smooth frame rate.
The MDN Web Performance Learning Area contains modern, up-to-date tutorials covering Performance essentials. Start here if you are a newcomer to performance:
This article discusses why web performance is important for accessibility, user experience and your business goals.
You know web performance is important, but what factors affect web perf