From 5fba08e90f061a4eb8c6ec9b8739657d429088a2 Mon Sep 17 00:00:00 2001 From: julieng Date: Thu, 15 Sep 2022 07:48:15 +0200 Subject: [PATCH] convert content to md --- .../critical_rendering_path/index.md | 55 +- files/pt-br/web/performance/index.md | 477 ++++++++---------- 2 files changed, 249 insertions(+), 283 deletions(-) diff --git a/files/pt-br/web/performance/critical_rendering_path/index.md b/files/pt-br/web/performance/critical_rendering_path/index.md index 51e97657a6c8f0..88dca07c63e10a 100644 --- a/files/pt-br/web/performance/critical_rendering_path/index.md +++ b/files/pt-br/web/performance/critical_rendering_path/index.md @@ -4,57 +4,56 @@ slug: Web/Performance/Critical_rendering_path translation_of: Web/Performance/Critical_rendering_path original_slug: Web/Performance/caminho_de_renderizacao_critico --- +**O caminho de renderização crítico** é a sequência de passos que o navegador passa para converter HTML, CSS e JavaScript em pixels na tela. Otimizando o caminho de renderização crítico melhora a performance.The critical rendering path includes the [Document Object Model ](/pt-BR/docs/Web/API/Document_Object_Model)(DOM), [CSS Object Model ](/pt-BR/docs/Web/API/CSS_Object_Model)(CSSOM), render tree and layout. -

O caminho de renderização crítico é a sequência de passos que o navegador passa para converter HTML, CSS e JavaScript em pixels na tela. Otimizando o caminho de renderização crítico melhora a performance.The critical rendering path includes the Document Object Model (DOM), CSS Object Model (CSSOM), render tree and layout.

+The document object model is created as the HTML is parsed. The HTML may request JavaScript, which may, in turn, alter the DOM. The HTML includes or makes requests for styles, which in turn builds the CSS object model. The browser engine combines the two to create the Render Tree. Layout determines the size and location of everything on the page. Once layout is determined, pixels are painted to the screen. -

The document object model is created as the HTML is parsed. The HTML may request JavaScript, which may, in turn, alter the DOM. The HTML includes or makes requests for styles, which in turn builds the CSS object model. The browser engine combines the two to create the Render Tree. Layout determines the size and location of everything on the page. Once layout is determined, pixels are painted to the screen.

+Optimizing the critical rendering path improves the time to first render. Understanding and optimizing the critical rendering path is important to ensure reflows and repaints can happen at 60 frames per second, to ensure performant user interactions and avoid jank. -

Optimizing the critical rendering path improves the time to first render. Understanding and optimizing the critical rendering path is important to ensure reflows and repaints can happen at 60 frames per second, to ensure performant user interactions and avoid jank.

+## Understanding CRP -

Understanding CRP

+Web performance includes the server requests and responses, loading, scripting, rendering, layout, and the painting of the pixels to the screen. -

Web performance includes the server requests and responses, loading, scripting, rendering, layout, and the painting of the pixels to the screen.

+A request for a web page or app starts with an HTML request. The server returns the HTML - response headers and data. The browser then begins parsing the HTML, converting the received bytes to the DOM tree. The browser initiates requests every time it finds links to external resources, be they stylesheets, scripts, or embedded image references. Some requests are blocking, which means the parsing of the rest of the HTML is halted until the imported asset is handled. The browser continues to parse the HTML making requests and building the DOM, until it gets to the end, at which point it constructs the CSS object model. With the DOM and CSSOM complete, the browser builds the render tree, computing the styles for all the visible content. After the render tree is complete, layout occurs, defining the location and size of all the render tree elements. Once complete, the page is rendered, or 'painted' on the screen. -

A request for a web page or app starts with an HTML request. The server returns the HTML - response headers and data. The browser then begins parsing the HTML, converting the received bytes to the DOM tree. The browser initiates requests every time it finds links to external resources, be they stylesheets, scripts, or embedded image references. Some requests are blocking, which means the parsing of the rest of the HTML is halted until the imported asset is handled. The browser continues to parse the HTML making requests and building the DOM, until it gets to the end, at which point it constructs the CSS object model. With the DOM and CSSOM complete, the browser builds the render tree, computing the styles for all the visible content. After the render tree is complete, layout occurs, defining the location and size of all the render tree elements. Once complete, the page is rendered, or 'painted' on the screen.

+### Document Object Model -

Document Object Model

+DOM construction is incremental. The HTML response turns into tokens which turns into nodes which turn into the DOM Tree. A single DOM node starts with a startTag token and ends with an endTag token. Nodes contain all relevant information about the HTML element. The information is described using tokens. Nodes are connected into a DOM tree based on token hierarchy. If another set of startTag and endTag tokens come between a set of startTag and endTags, you have a node inside a node, which is how we define the hierarchy of the DOM tree. -

DOM construction is incremental. The HTML response turns into tokens which turns into nodes which turn into the DOM Tree. A single DOM node starts with a startTag token and ends with an endTag token. Nodes contain all relevant information about the HTML element. The information is described using tokens. Nodes are connected into a DOM tree based on token hierarchy. If another set of startTag and endTag tokens come between a set of startTag and endTags, you have a node inside a node, which is how we define the hierarchy of the DOM tree.

+The greater the number of nodes, the longer the following events in the critical rendering path will take. Measure! A few extra nodes won't make a difference, but divitis can lead to jank. -

The greater the number of nodes, the longer the following events in the critical rendering path will take. Measure! A few extra nodes won't make a difference, but divitis can lead to jank.

+### CSS Object Model -

CSS Object Model

+The DOM contains all the content of the page. The CSSOM contains all the styles of the page; information on how to style that DOM. CSSOM is similar the the DOM, but different. While the DOM construction is incremental, CSSOM is not. CSS is render blocking: the browser blocks page rendering until it receives and processes all of the CSS. CSS is render blocking because rules can be overwritten, so the content can't be rendered until the CSSOM is complete. -

The DOM contains all the content of the page. The CSSOM contains all the styles of the page; information on how to style that DOM. CSSOM is similar the the DOM, but different. While the DOM construction is incremental, CSSOM is not. CSS is render blocking: the browser blocks page rendering until it receives and processes all of the CSS. CSS is render blocking because rules can be overwritten, so the content can't be rendered until the CSSOM is complete.

+CSS has its own set of rules for identifying valid tokens. Remember the C in CSS stands for 'Cascade'. CSS rules cascade down. As the parser converts tokens to nodes, with descendants of nodes inheriting styles. The incremental processing features don't apply to CSS like they do with HTML, because subsequent rules may override previous ones. The CSS object model gets built as the CSS is parsed, but can't be used to build the render tree until it is completely parsed because styles that are going to be overwritten with later parsing should not be rendered to the screen. -

CSS has its own set of rules for identifying valid tokens. Remember the C in CSS stands for 'Cascade'. CSS rules cascade down. As the parser converts tokens to nodes, with descendants of nodes inheriting styles. The incremental processing features don't apply to CSS like they do with HTML, because subsequent rules may override previous ones. The CSS object model gets built as the CSS is parsed, but can't be used to build the render tree until it is completely parsed because styles that are going to be overwritten with later parsing should not be rendered to the screen.

+In terms of selector performance, less specific selectors are faster than more specific ones. For example, `.foo {}` is faster than `.bar .foo {}` because when the browser finds `.foo`, in the second scenario, it has to walk up the DOM to check if `.foo` has an ancestor `.bar`. The more specific tag requires more work from the browser, but this penalty is not likely worth optimizing. -

In terms of selector performance, less specific selectors are faster than more specific ones. For example, .foo {} is faster than .bar .foo {} because when the browser finds .foo, in the second scenario, it has to walk up the DOM to check if .foo has an ancestor .bar. The more specific tag requires more work from the browser, but this penalty is not likely worth optimizing.

+If you measure the time it takes to parse CSS, you'll be amazed at how fast browsers truly are. The more specific rule is more expensive because it has to traverse more nodes in the DOM tree - but that extra expense is generally minimal. Measure first. Optimize as needed. Specificity is likely not your low hanging fruit. When it comes to CSS, selector performance optimization, improvements will only be in microseconds. There are other [ways to optimize CSS](/pt-BR/docs/Learn/Performance/CSS_performance), such as minification, and separating defered CSS into non-blocking requests by using media queries. -

If you measure the time it takes to parse CSS, you'll be amazed at how fast browsers truly are. The more specific rule is more expensive because it has to traverse more nodes in the DOM tree - but that extra expense is generally minimal. Measure first. Optimize as needed. Specificity is likely not your low hanging fruit. When it comes to CSS, selector performance optimization, improvements will only be in microseconds. There are other ways to optimize CSS, such as minification, and separating defered CSS into non-blocking requests by using media queries.

+### Render Tree -

Render Tree

+The render tree captures both the content and the styles: the DOM and CSSOM trees are combined into the render tree. To construct the render tree, the browser checks every node, starting from root of the DOM tree, and determine which CSS rules are attached. -

The render tree captures both the content and the styles: the DOM and CSSOM trees are combined into the render tree. To construct the render tree, the browser checks every node, starting from root of the DOM tree, and determine which CSS rules are attached.

+The render tree only captures visible content. The head section (generally) doesn't contain any visible information, and is therefore not included in the render tree. If there's a display: none; set on an element, neither it, nor any of its descendants, are in the render tree. -

The render tree only captures visible content. The head section (generally) doesn't contain any visible information, and is therefore not included in the render tree. If there's a display: none; set on an element, neither it, nor any of its descendants, are in the render tree.

+### Layout -

Layout

+Once the render tree is built, layout becomes possible. Layout is dependent on the size of screen. The layout step determines where and how the elements are positioned on the page, determining the width and height of each element, and where they are in relation to each other. -

Once the render tree is built, layout becomes possible. Layout is dependent on the size of screen. The layout step determines where and how the elements are positioned on the page, determining the width and height of each element, and where they are in relation to each other.

+What is the width of an element? Block level elements, by definition, have a default width of 100% of the width of their parent. An element with a width of 50%, will be half of the width of its parent. Unless otherwise defined, the body has a width of 100%, meaning it will be 100% of the width of the viewport. This width of the device impacts layout. -

What is the width of an element? Block level elements, by definition, have a default width of 100% of the width of their parent. An element with a width of 50%, will be half of the width of its parent. Unless otherwise defined, the body has a width of 100%, meaning it will be 100% of the width of the viewport. This width of the device impacts layout.

+The viewport meta tag defines the width of the layout viewport, impacting the layout. Without it, the browser uses the default viewport width, which on by-default full screen browsers is generally 960px. On by-default full screen browsers, like your phone's browser, by setting ``, the width will be the width of the device instead of the default viewport width. The device-width changes when a user rotates their phone between landscape and portrait mode. Layout happens every time a device is rotated or browser is otherwise resized. -

The viewport meta tag defines the width of the layout viewport, impacting the layout. Without it, the browser uses the default viewport width, which on by-default full screen browsers is generally 960px. On by-default full screen browsers, like your phone's browser, by setting <meta name="viewport" content="width=device-width">, the width will be the width of the device instead of the default viewport width. The device-width changes when a user rotates their phone between landscape and portrait mode. Layout happens every time a device is rotated or browser is otherwise resized.

+Layout performance is impacted by the DOM -- the greater the number of nodes, the longer layout takes. Layout can become a bottleneck, leading to jank if required during scrolling or other animations. While a 20ms layout on load or orientation change may be fine, it will lead to jank on animation or scroll. Any time the render tree is modified, such as by added nodes, altered content, or updated box model styles on a node, layout occurs. -

Layout performance is impacted by the DOM -- the greater the number of nodes, the longer layout takes. Layout can become a bottleneck, leading to jank if required during scrolling or other animations. While a 20ms layout on load or orientation change may be fine, it will lead to jank on animation or scroll. Any time the render tree is modified, such as by added nodes, altered content, or updated box model styles on a node, layout occurs.

+To reduce the frequency and duration of layout events, batch updates and avoid animating box model properties. -

To reduce the frequency and duration of layout events, batch updates and avoid animating box model properties.

+### Paint -

Paint

+The last step in painting the pixels to the screen. Once the render tree is created and layout occurs, the pixels can be painted to the screen. Onload, the entire screen is painted. After that, only impacted areas of the screen will be repainted, as browsers are optimized to repaint the minimum area required. Paint time depends on what kind of updates are being applied to the render tree. While painting is a very fast process, and therefore likely not the most impactful place to focus on in improving performance, it is important to remember to allow for both layout and re-paint times when measuring how long an animation frame may take. The styles applied to each node increase the paint time, but removing style that increases the paint by 0.001ms may not give you the biggest bang for your optimization buck. Remember to measure first. Then you can determine whether it should be an optimization priority. -

The last step in painting the pixels to the screen. Once the render tree is created and layout occurs, the pixels can be painted to the screen. Onload, the entire screen is painted. After that, only impacted areas of the screen will be repainted, as browsers are optimized to repaint the minimum area required. Paint time depends on what kind of updates are being applied to the render tree. While painting is a very fast process, and therefore likely not the most impactful place to focus on in improving performance, it is important to remember to allow for both layout and re-paint times when measuring how long an animation frame may take. The styles applied to each node increase the paint time, but removing style that increases the paint by 0.001ms may not give you the biggest bang for your optimization buck. Remember to measure first. Then you can determine whether it should be an optimization priority.

+## Optimizing for CRP -

Optimizing for CRP

- -

Improve page load speed by prioritizing which resources get loaded, controlling the order in which they area loaded, and reducing the file sizes of those resources. Performance tips include 1) minimizing the number of critical resources by deferring their download, marking them as async, or eliminating them altogether, 2) optimizing the number of requests required along with the file size of each request, and 3) optimizing the order in which critical resources are loaded by prioritizing the downloading critical assets, shorten the critical path length.

+Improve page load speed by prioritizing which resources get loaded, controlling the order in which they area loaded, and reducing the file sizes of those resources. Performance tips include 1) minimizing the number of critical resources by deferring their download, marking them as async, or eliminating them altogether, 2) optimizing the number of requests required along with the file size of each request, and 3) optimizing the order in which critical resources are loaded by prioritizing the downloading critical assets, shorten the critical path length. diff --git a/files/pt-br/web/performance/index.md b/files/pt-br/web/performance/index.md index 33e6c38de98b8f..103f490cb61558 100644 --- a/files/pt-br/web/performance/index.md +++ b/files/pt-br/web/performance/index.md @@ -19,258 +19,225 @@ tags: - Web Performance translation_of: Web/Performance --- -

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 - is the scrolling smooth? are buttons clickable? Are pop-ups quick to load and display, and do they animate smoothly as they do so? Web performance includes both objective measurements like time to load, frames per second, and time to become interactive, and subjective experiences of how long it felt like it took the 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 this section:

- -

Key performance guides

- -

{{LandingPageListSubpages}}

- -

Beginner's tutorials

- -

The MDN Web Performance Learning Area contains modern, up-to-date tutorials covering Performance essentials. Start here if you are a newcomer to performance:

- -
-
-
Web performance: brief overview
-
Overview of the web performance learning path. Start your journey here.
-
What is web performance?
-
This article starts the module off with a good look at what performance actually is — this includes the tools, metrics, APIs, networks, and groups of people we need to consider when thinking about performance, and how we can make performance part of our web development workflow.
-
How do users perceive performance?
-
-

More important than how fast your website is in milliseconds, is how fast your users perceive your site to be. These perceptions are impacted by actual page load time, idling, responsiveness to user interaction, and the smoothness of scrolling and other animations. In this article, we discuss the various loading metrics, animation, and responsiveness metrics, along with best practices to improve user perception, if not the actual timings.

-
-
Web performance basics
-
In addition to the front end components of HTML, CSS, JavaScript, and media files, there are features that can make applications slower and features that can make applications subjectively and objectively faster. There are many APIs, developer tools, best practices, and bad practices relating to web performance. Here we'll introduce many of these features ad the basic level and provide links to deeper dives to improve performance for each topic.
-
HTML performance features
-
Some attributes and the source order of your mark-up can impact the performance or your website. By minimizing the number of DOM nodes, making sure the best order and attributes are used for including content such as styles, scripts, media, and third-party scripts, you can drastically improve the user experience. This article looks in detail at how HTML can be used to ensure maximum performance.
-
Multimedia: images and video
-
The lowest hanging fruit of web performance is often media optimization. Serving different media files based on each user agent's capability, size, and pixel density is possible. Additional tips like removing audio tracks from background videos can improve performance even further. In this article we discuss the impact video, audio, and image content has on performance, and the methods to ensure that impact is as minimal as possible.
-
CSS performance features
-
CSS may be a less important optimization focus for improved performance, but there are some CSS features that impact performance more than others. In this article we look at some CSS properties that impact performance and suggested ways of handling styles to ensure performance is not negatively impacted.
-
JavaScript performance best practices
-
JavaScript, when used properly, can allow for interactive and immersive web experiences — or it can significantly harm download time, render time, in-app performance, battery life, and user experience. This article outlines some JavaScript best practices that should be considered to ensure even complex content is as performant as possible.
-
Mobile performance
-
With web access on mobile devices being so popular, and all mobile platforms having fully-fledged web browsers, but possibly limited bandwidth, CPU and battery life, it is important to consider the performance of your web content on these platforms. This article looks at mobile-specific performance considerations.
-
- -

Using Performance APIs

- -
-
Performance API
-
This guide describes how to use the Performance interfaces that are defined in the High-Resolution Time standard.
-
Resource Timing API
-
Resource loading and timing the loading of those resources, including managing the resource buffer and coping with CORS
-
The performance timeline
-
The Performance Timeline standard defines extensions to the Performance interface to support client-side latency measurements within applications. Together, these interfaces can be used to help identify an application's performance bottlenecks.
-
User Timing API
-
Create application specific timestamps using the user timing API's "mark" and "measure" entry types - that are part of the browser's performance timeline.
-
Frame Timing API
-
The PerformanceFrameTiming interface provides frame timing data about the browser's event loop.
-
Beacon API
-
The Beacon interface schedules an asynchronous and non-blocking request to a web server.
-
Intersection Observer API
-
Learn to time element visibility with the Intersection Observer API and be asynchronously notified when elements of interest becomes visible.
-
- -

Other documentation

- -
-
Developer Tools Performance Features
-
This section provides information on how to use and understand the performance features in your developer tools, including Waterfall, Call Tree, and Flame Charts.
-
Profiling with the built-in profiler
-
Learn how to profile app performance with Firefox's built-in profiler.
-
- -

Glossary Terms

- - - -

Documents yet to be written

- -
-
JavaScript performance best practices
-
JavaScript, when used properly, can allow for interactive and immersive web experiences ... or it can significantly harm download time, render time, in app performance, battery life, and user experience. This article outlines some JavaScript best practices that can ensure even complex content's performance is the highest possible.
-
Mobile performance
-
With web access on mobile devices being so popular, and all mobile platforms having fully-fledged web browsers, but possibly limited bandwidth, CPU, and battery life, it is important to consider the performance of your web content on these platforms. This article also looks at mobile-specific performance considerations.
-
Web font performance
-
An often overlooked aspect of performance landscape are web fonts. Web fonts are more prominent in web design than ever, yet many developers simply embed them from a third party service and think nothing of it. In this article, we'll covers methods for getting your font files as small as possible with efficient file formats and sub setting. From there, we'll go on to talk about how browsers text, and how you can use CSS and JavaScript features to ensure your fonts render quickly, and with minimal disruption to the user experience.
-
Performance bottlenecks
-
…
-
Understanding bandwidth
-
Bandwidth is the amount of data measured in Megabits(Mb) or Kilobits(Kb) that one can send per second. This article explains the role of bandwidth in media-rich internet applications, how you can measure it, and how you can optimize applications to make the best use of available bandwidth -
-
The role of TLS in performance
-
-

TLS—or HTTPS as we tend to call it—is crucial in creating secure and safe user experiences. While hardware has reduced the negative impacts TLS has had on server performance, it still represents a substantial slice of the time we spend waiting for browsers to connect to servers. This article explains the TLS handshake process, and offers some tips for reducing this time, such as OCSP stapling, HSTS preload headers, and the potential role of resource hints in masking TLS latency for third parties.

-
-
Reading performance charts
-
Developer tools provide information on performance, memory, and network requests. Knowing how to read waterfall charts, call trees, traces, flame charts , and allocations in your browser developer tools will help you understand waterfall and flame charts in other performance tools.
-
Alternative media formats
-
When it comes to images and videos, there are more formats than you're likely aware of. Some of these formats can take your highly optimized media-rich pages even further by offering additional reductions in file size. In this guide we'll discuss some alternative media formats, how to use them responsibly so that non-supporting browsers don't get left out in the cold, and some advanced guidance on transcoding your existing assets to them.
-
Analyzing JavaScript bundles
-
No doubt, JavaScript is a big part of modern web development. While you should always strive to reduce the amount of JavaScript you use in your applications, it can be difficult to know where to start. In this guide, we'll show you how to analyze your application's script bundles, so you know what you're using, as well how to detect if your app contains duplicated scripts between bundles.
-
Lazy loading
-
It isn't always necessary to load all of a web applications assets on initial page load. Lazy Loading is deferring the loading of assets on a page, such as scripts, images, etc., on a page to a later point in time i.e when those assets are actually needed.
-
Lazy-loading JavaScript with dynamic imports
-
When developers hear the term "lazy loading", they immediately think of below-the-fold imagery that loads when it scrolls into the viewport. But did you know you can lazy load JavaScript as well? In this guide we'll talk about the dynamic import() statement, which is a feature in modern browsers that loads a JavaScript module on demand. Of course, since this feature isn't available everywhere, we'll also show you how you can configure your tooling to use this feature in a widely compatible fashion.
-
Controlling resource delivery with resource hints
-
Browsers often know better than we do when it comes to resource prioritization and delivery however they're far from clairyovant. Native browser features enable us to hint to the browser when it should connect to another server, or preload a resource before the browser knows it ever needs it. When used judiciously, this can make fast experience seem even faster. In this article, we cover native browser features like rel=preconnect, rel=dns-prefetch, rel=prefetch, and rel=preload, and how to use them to your advantage.
-
Performance Budgets
-
Marketing, design, and sales needs, and developer experience, often ad bloat, third-party scripts, and other features that can slow down web performance. To help set priorities, it is helpful to set a performance budget: a set of restrictions to not exceed during the development phase. In this article, we'll discuss creating and sticking to a performance budget.
-
Web performance checklist
-
A performance checklist of features to consider when developing applications with links to tutorials on how to implement each feature, include service workers, diagnosing performance problems, font loading best practices, client hints, creating performant animations, etc.
-
Mobile performance checklist
-
A concise checklist of performance considerations impacting mobile network users on hand-held, battery operated devices.
-
- -

See also

- -

HTML

- - - -

CSS

- - - -

JavaScript

- - - -

APIs

- - - -

Headers

- - - -

Tools

- - - -

Additional Metrics

- - - -

Best Practices

- - +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 - is the scrolling smooth? are buttons clickable? Are pop-ups quick to load and display, and do they animate smoothly as they do so? Web performance includes both objective measurements like time to load, frames per second, and time to become interactive, and subjective experiences of how long it felt like it took the 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 this section: + +## Key performance guides + +{{LandingPageListSubpages}} + +## Beginner's tutorials + +The MDN [Web Performance Learning Area](/pt-BR/docs/Learn/Performance) contains modern, up-to-date tutorials covering Performance essentials. Start here if you are a newcomer to performance: + +- [Web performance: brief overview](/pt-BR/docs/Learn/Performance/web_performance_overview) + + - : Overview of the web performance learning path. Start your journey here. + +- [What is web performance?](/pt-BR/docs/Learn/Performance/What_is_web_performance) + - : This article starts the module off with a good look at what performance actually is — this includes the tools, metrics, APIs, networks, and groups of people we need to consider when thinking about performance, and how we can make performance part of our web development workflow. +- [How do users perceive performance?](/pt-BR/docs/Learn/Performance/Perceived_performance) + - : More important than how fast your website is in milliseconds, is how fast your users perceive your site to be. These perceptions are impacted by actual page load time, idling, responsiveness to user interaction, and the smoothness of scrolling and other animations. In this article, we discuss the various loading metrics, animation, and responsiveness metrics, along with best practices to improve user perception, if not the actual timings. +- [Web performance basics](/pt-BR/docs/Learn/Performance/Web_Performance_Basics) + - : In addition to the front end components of HTML, CSS, JavaScript, and media files, there are features that can make applications slower and features that can make applications subjectively and objectively faster. There are many APIs, developer tools, best practices, and bad practices relating to web performance. Here we'll introduce many of these features ad the basic level and provide links to deeper dives to improve performance for each topic. +- [HTML performance features](/pt-BR/docs/Learn/Performance/HTML) + - : Some attributes and the source order of your mark-up can impact the performance or your website. By minimizing the number of DOM nodes, making sure the best order and attributes are used for including content such as styles, scripts, media, and third-party scripts, you can drastically improve the user experience. This article looks in detail at how HTML can be used to ensure maximum performance. +- [Multimedia: images and video](/pt-BR/docs/Learn/Performance/Multimedia) + - : The lowest hanging fruit of web performance is often media optimization. Serving different media files based on each user agent's capability, size, and pixel density is possible. Additional tips like removing audio tracks from background videos can improve performance even further. In this article we discuss the impact video, audio, and image content has on performance, and the methods to ensure that impact is as minimal as possible. +- [CSS performance features](/pt-BR/docs/Learn/Performance/CSS) + - : CSS may be a less important optimization focus for improved performance, but there are some CSS features that impact performance more than others. In this article we look at some CSS properties that impact performance and suggested ways of handling styles to ensure performance is not negatively impacted. +- [JavaScript performance best practices](/pt-BR/docs/Learn/Performance/JavaScript) + - : JavaScript, when used properly, can allow for interactive and immersive web experiences — or it can significantly harm download time, render time, in-app performance, battery life, and user experience. This article outlines some JavaScript best practices that should be considered to ensure even complex content is as performant as possible. +- [Mobile performance](/pt-BR/docs/Learn/Performance/Mobile) + - : With web access on mobile devices being so popular, and all mobile platforms having fully-fledged web browsers, but possibly limited bandwidth, CPU and battery life, it is important to consider the performance of your web content on these platforms. This article looks at mobile-specific performance considerations. + +## Using Performance APIs + +- [Performance API](/pt-BR/docs/Web/API/Performance_API/Using_the_Performance_API) + - : This guide describes how to use the [`Performance`](/pt-BR/docs/Web/API/Performance "The Performance interface provides access to performance-related information for the current page. It's part of the High Resolution Time API, but is enhanced by the Performance Timeline API, the Navigation Timing API, the User Timing API, and the Resource Timing API.") interfaces that are defined in the [High-Resolution Time](https://w3c.github.io/hr-time/) standard. +- [Resource Timing API](/pt-BR/docs/Web/API/Resource_Timing_API/Using_the_Resource_Timing_API) + - : [Resource loading and timing](/pt-BR/docs/Web/API/Resource_Timing_API) the loading of those resources, including managing the resource buffer and coping with CORS +- [The performance timeline](/pt-BR/docs/Web/API/Performance_Timeline/Using_Performance_Timeline) + - : The [Performance Timeline](/pt-BR/docs/Web/API/Performance_Timeline) standard defines extensions to the [`Performance`](/pt-BR/docs/Web/API/Performance "The Performance interface provides access to performance-related information for the current page. It's part of the High Resolution Time API, but is enhanced by the Performance Timeline API, the Navigation Timing API, the User Timing API, and the Resource Timing API.") interface to support client-side latency measurements within applications. Together, these interfaces can be used to help identify an application's performance bottlenecks. +- [User Timing API](/pt-BR/docs/Web/API/User_Timing_API/Using_the_User_Timing_API) + - : Create application specific timestamps using the [user timing API](/pt-BR/docs/Web/API/User_Timing_API)'s "mark" and "measure" entry types - that are part of the browser's performance timeline. +- [Frame Timing API](/pt-BR/docs/Web/API/Frame_Timing_API/Using_the_Frame_Timing_API) + - : The [`PerformanceFrameTiming`](/en-US/docs/Web/API/PerformanceFrameTiming) interface provides _frame_ timing data about the browser's event loop. +- [Beacon API](/pt-BR/docs/Web/API/Beacon_API/Using_the_Beacon_API) + - : The [Beacon](/pt-BR/docs/Web/API/Beacon_API) interface schedules an asynchronous and non-blocking request to a web server. +- [Intersection Observer API](/pt-BR/docs/Web/API/Intersection_Observer_API/Timing_element_visibility) + - : Learn to time element visibility with the [Intersection Observer API](/pt-BR/docs/Web/API/Intersection_Observer_API) and be asynchronously notified when elements of interest becomes visible. + +## Other documentation + +- [Developer Tools Performance Features](/pt-BR/docs/Tools/Performance) + - : This section provides information on how to use and understand the performance features in your developer tools, including [Waterfall](/pt-BR/docs/Tools/Performance/Waterfall), [Call Tree](/pt-BR/docs/Tools/Performance/Call_Tree), and [Flame Charts](/pt-BR/docs/Tools/Performance/Flame_Chart). +- [Profiling with the built-in profiler](/pt-BR/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler) + - : Learn how to profile app performance with Firefox's built-in profiler. + +## Glossary Terms + +- {{glossary('Beacon')}} +- {{glossary('Brotli compression')}} +- {{glossary('Client hints')}} +- {{glossary('Code splitting')}} +- {{glossary('CSSOM')}} +- {{glossary('Domain sharding')}} +- {{glossary('Effective connection type')}} +- {{glossary('First contentful paint')}} +- {{glossary('First CPU idle')}} +- {{glossary('First input delay')}} +- {{glossary('First interactive')}} +- {{glossary('First meaningful paint')}} +- {{glossary('First paint')}} +- {{glossary('HTTP')}} +- {{glossary('HTTP_2', 'HTTP/2')}} +- {{glossary('Jank')}} +- {{glossary('Latency')}} +- {{glossary('Lazy load')}} +- {{glossary('Long task')}} +- {{glossary('Lossless compression')}} +- {{glossary('Lossy compression')}} +- {{glossary('Main thread')}} +- {{glossary('Minification')}} +- {{glossary('Network throttling')}} +- {{glossary('Packet')}} +- {{glossary('Page load time')}} +- {{glossary('Page prediction')}} +- {{glossary('Parse')}} +- {{glossary('Perceived performance')}} +- {{glossary('Prefetch')}} +- {{glossary('Prerender')}} +- {{glossary('QUIC')}} +- {{glossary('RAIL')}} +- {{glossary('Real User Monitoring')}} +- {{glossary('Resource Timing')}} +- {{glossary('Round Trip Time (RTT)')}} +- {{glossary('Server Timing')}} +- {{glossary('Speculative parsing')}} +- {{glossary('Speed index')}} +- {{glossary('SSL')}} +- {{glossary('Synthetic monitoring')}} +- {{glossary('TCP handshake')}} +- {{glossary('TCP slow start')}} +- {{glossary('Time to first byte')}} +- {{glossary('Time to interactive')}} +- {{glossary('TLS')}} +- {{glossary('TCP', 'Transmission Control Protocol (TCP)')}} +- {{glossary('Tree shaking')}} +- {{glossary('Web performance')}} + +## Documents yet to be written + +- [JavaScript performance best practices](/pt-BR/docs/Learn/Performance/JavaScript) + - : JavaScript, when used properly, can allow for interactive and immersive web experiences ... or it can significantly harm download time, render time, in app performance, battery life, and user experience. This article outlines some JavaScript best practices that can ensure even complex content's performance is the highest possible. +- [Mobile performance](/pt-BR/docs/Learn/Performance/Mobile) + - : With web access on mobile devices being so popular, and all mobile platforms having fully-fledged web browsers, but possibly limited bandwidth, CPU, and battery life, it is important to consider the performance of your web content on these platforms. This article also looks at mobile-specific performance considerations. +- Web font performance + - : An often overlooked aspect of performance landscape are web fonts. Web fonts are more prominent in web design than ever, yet many developers simply embed them from a third party service and think nothing of it. In this article, we'll covers methods for getting your font files as small as possible with efficient file formats and sub setting. From there, we'll go on to talk about how browsers text, and how you can use CSS and JavaScript features to ensure your fonts render quickly, and with minimal disruption to the user experience. +- Performance bottlenecks + - : … +- Understanding bandwidth + - : Bandwidth is the amount of data measured in Megabits(Mb) or Kilobits(Kb) that one can send per second. This article explains the role of bandwidth in media-rich internet applications, how you can measure it, and how you can optimize applications to make the best use of available bandwidth +- The role of TLS in performance + - : TLS—or HTTPS as we tend to call it—is crucial in creating secure and safe user experiences. While hardware has reduced the negative impacts TLS has had on server performance, it still represents a substantial slice of the time we spend waiting for browsers to connect to servers. This article explains the TLS handshake process, and offers some tips for reducing this time, such as OCSP stapling, HSTS preload headers, and the potential role of resource hints in masking TLS latency for third parties. +- Reading performance charts + - : Developer tools provide information on performance, memory, and network requests. Knowing how to read [waterfall](/pt-BR/docs/Tools/Performance/Waterfall) charts, [call trees](/pt-BR/docs/Tools/Performance/Call_Tree), traces, [flame charts](/pt-BR/docs/Tools/Performance/Flame_Chart) , and [allocations](/pt-BR/docs/Tools/Performance/Allocations) in your browser developer tools will help you understand waterfall and flame charts in other performance tools. +- Alternative media formats + - : When it comes to images and videos, there are more formats than you're likely aware of. Some of these formats can take your highly optimized media-rich pages even further by offering additional reductions in file size. In this guide we'll discuss some alternative media formats, how to use them responsibly so that non-supporting browsers don't get left out in the cold, and some advanced guidance on transcoding your existing assets to them. +- Analyzing JavaScript bundles + - : No doubt, JavaScript is a big part of modern web development. While you should always strive to reduce the amount of JavaScript you use in your applications, it can be difficult to know where to start. In this guide, we'll show you how to analyze your application's script bundles, so you know _what_ you're using, as well how to detect if your app contains duplicated scripts between bundles. +- [Lazy loading](/pt-BR/docs/Web/Performance/Lazy_loading) + - : It isn't always necessary to load all of a web applications assets on initial page load. Lazy Loading is deferring the loading of assets on a page, such as scripts, images, etc., on a page to a later point in time i.e when those assets are actually needed. +- Lazy-loading JavaScript with dynamic imports + - : When developers hear the term "lazy loading", they immediately think of below-the-fold imagery that loads when it scrolls into the viewport. But did you know you can lazy load JavaScript as well? In this guide we'll talk about the dynamic import() statement, which is a feature in modern browsers that loads a JavaScript module on demand. Of course, since this feature isn't available everywhere, we'll also show you how you can configure your tooling to use this feature in a widely compatible fashion. +- [Controlling resource delivery with resource hints](/pt-BR/docs/Web/Performance/Controlling_resource_delivery_with_resource_hints) + - : Browsers often know better than we do when it comes to resource prioritization and delivery however they're far from clairyovant. Native browser features enable us to hint to the browser when it should connect to another server, or preload a resource before the browser knows it ever needs it. When used judiciously, this can make fast experience seem even faster. In this article, we cover native browser features like rel=preconnect, rel=dns-prefetch, rel=prefetch, and rel=preload, and how to use them to your advantage. +- [Performance Budgets](/pt-BR/docs/Web/Performance/Performance_budgets) + - : Marketing, design, and sales needs, and developer experience, often ad bloat, third-party scripts, and other features that can slow down web performance. To help set priorities, it is helpful to set a performance budget: a set of restrictions to not exceed during the development phase. In this article, we'll discuss creating and sticking to a performance budget. +- [Web performance checklist](/pt-BR/docs/Web/Performance/Checklist) + - : A performance checklist of features to consider when developing applications with links to tutorials on how to implement each feature, include service workers, diagnosing performance problems, font loading best practices, client hints, creating performant animations, etc. +- [Mobile performance checklist](/pt-BR/docs/Web/Performance/Mobile_performance_checklist) + - : A concise checklist of performance considerations impacting mobile network users on hand-held, battery operated devices. + +## See also + +HTML + +- [The `` Element](/pt-BR/docs/Web/HTML/Element/picture) +- [The `