remove retired locales (#699)

2 files changed, 0 insertions, 349 deletions

diff --git a/files/it/web/performance/critical_rendering_path/index.html b/files/it/web/performance/critical_rendering_path/index.html
deleted file mode 100644
index d80bf04f96..0000000000
--- a/files/it/web/performance/critical_rendering_path/index.html
+++ /dev/null
@@ -1,63 +0,0 @@
----
-title: Percorso critico di rendering
-slug: Web/Performance/Critical_rendering_path
-translation_of: Web/Performance/Critical_rendering_path
-original_slug: Web/Performance/Percorso_critico_di_rendering
----
-<p>{{draft}}</p>
-
-<p><span class="seoSummary">Il <strong>Percorso Critico di Rendering </strong>(in inglese: Critical Rendering Path, <strong>CRP</strong>) è la sequenza di passi che il browser compie per convertire HTML, CSS e Javascript in pixel sullo schermo. Ottimizzare il CRP migliora la performance. Il percorso include il</span><span class="seoSummary"><a href="/en-US/docs/Web/API/Document_Object_Model">Document Object Model </a>(DOM), il <a href="/en-US/docs/Web/API/CSS_Object_Model">CSS Object Model </a>(CSSOM), l'albero di rendering e il layout.</span></p>
-
-<p>Il DOM è creato man mano che l'HTML viene parsificato. L'HTML può richiedere Javascript, il quale potrebbe a sua volte alterare il <strong>DOM</strong>. L'HTML include o richiede fogli di stile, la cui parsificazione costruisce il <strong>CSSOM</strong>. Il motore del browser combina il DOM e il CSSOM per costruire l'albero di rendering. La fase di layout determina le dimensioni e posizione di ogni elemento della pagine. Infine, i pixel sono dipinti sullo schermo.</p>
-
-<p>Ottimizzare il CRP migliora il tempo che il browser impiega ad effettuare il primo render. Capire e ottimizzare il percorso critico di rendering è importante per assicurarsi che i reflow e repaint vengano effettuato a 60 frame al secondo, risultando in una migliore esperienza per l'utente.</p>
-
-<h2 id="Capire_il_CRP">Capire il CRP</h2>
-
-<p>La performance di un sito web dipende dal tempo impiegato per effettuare richieste al server, risposte, caricare risorse, eseguire script, rendering, layout, e dipingere i pixel sullo schermo.</p>
-
-<p>Una richiesta per una pagina web o una web app inizia con una richiesta HTML. Il server risponde alla richiesta con il codice sorgente in linguaggio HTML. A questo punto, il browser inizia a parsificare l'HTML, costrudendo l'albero DOM.</p>
-
-<p>Il browser manda ulteriori richieste ogni volta che trova link a risorse esterne, che siano fogli di stile, script, o referenze a immagini. Alcune richieste sono <strong>bloccanti</strong>, il che significa che la parsificazione del resto dell'HTML viene interrotta fino a quando la risorsa importata non viene scaricata e manipolata. In seguito, il browser continua a parsificare l'HTML fino ad arrivare alla fine del file. A questo punto, il browser comincia a costruire il CSSOM. Quando il DOM e il CSSOM sono completi, il browser costruisce l'albero di rendering, calcolando gli stili per tutto il contenuto visibile. Quando l'albero è completo, viene calcolato il layout, che definisce le dimensioni e posizione di tutti gli elementi dell'albero di rendering. Una volta completato, la pagina viene "dipinta" sullo schermo.</p>
-
-<h3 id="Document_Object_Model">Document Object Model</h3>
-
-<p>La costruzione del DOM è incrementale. La risposta HTML si transforma in token, la quale si trasforma in nodi che costituiscono l'albero DOM. Un singolo nodo DOM comincia con un token startTag e finisce con un token endTag. I nodi contengono tutte le informazioni rilevanti sull'elemento HTML, descritta attraversi i token. I nodi sono connessi in un albero DOM in base alla gerarchia dei token. Per esempio, se un paio di token startTag ed endTag appaiono nel mezzo di un altro paio, questo genera un nodo padre ed un nodo figlio.</p>
-
-<p>Un grande numero di nodi può dunque impattare la performance, complicando il critical rendering path.</p>
-
-<h3 id="CSS_Object_Model">CSS Object Model</h3>
-
-<p>Il DOM contiene l'intero contenuto della pagina. il CSSOM contiene tutti gli stili. La costruzione del DOM è incrementale, ma quella del CSSOM non lo è. Il CSS è render-blocking: il browser blocca il rendering di una pagina finché non riceve e processa tutto il CSS. Questo perché le regole possono essere sovrascritte, quindi il contenuto non può essere mostrato fino a quando il CSS non è completo. </p>
-
-<p>Il CSS ha le proprie regole per identificare token validi. Quando il parser converte i token in nodi, i nodi discendenti ereditano regole dai genitori. Il CSSOM viene costruito mentre il CSS viene parsificato, ma non può essere usato per costruire il render tree fino a quando la parsificazione viene completata perché stili che vengono sovrascritti in seguito non devono essere visualizzati.</p>
-
-<p>Selettori meno specifici sono più performanti. Per esempio, <code>.foo {}</code> è più veloce di <code>.bar .foo {}</code> perché quando il browser trova <code>.foo</code>, nel secondo scenario, deve salire nel DOM per controllare se <code>.foo</code> ha un genitore <code>.bar</code>.</p>
-
-<p>I browser processano il CSS molto rapidamente. La regola specifica è più lenta perché deve attraversare più nodi nell'albero DOM, ma questo costo aggiuntivo è solitamente minimo. L'ottimizzazione dei selettori CSS solitamente porta a velocizzazioni nell'ordine dei microsecondi. Ci sono altri modi più efficaci per ottimizzare il CSS, come la mininizzazione, e separare il CSS in richieste non-blocking usando media queries.</p>
-
-<h3 id="Lalbero_di_rendering">L'albero di rendering</h3>
-
-<p>L'albero di rendering cattura sia il contenuto che gli stili combinando il DOM ed il CSSOM. Per costruirlo, il browser controlla ogni nodo, a partire dalla radice dell'albero DOM, e determina quali regole CSS sono applicate al nodo.</p>
-
-<p>L'albero di rendering mantiene informazioni solo su elementi visibili. La sezione head solitamente non contiene informazioni visibili, e quindi non è inclusa. Se display: none; è settato su un elemento, né questo elemento né i suoi discendenti sono inclusi.</p>
-
-<h3 id="Layout">Layout</h3>
-
-<p>Quando l'albero di rendering è completamente costruito, il layout diventa possibile. Il layout dipende dalle dimensioni dello schermo e determina dove e come gli elementi sono posizionati nella pagina, inclusi largezza ed altezza di ogni elemento, e dove sono posizionati rispetto ad altri elementi.</p>
-
-<p>Elementi block-level hanno una largezza in default di 100% del genitore. L'elemento body ha una larghezza dal 100% del viewport.</p>
-
-<p>Il meta tag "viewport" definisce la larghezza del viewport. In assenza di questo tag, il browser usa la larghezza viewport di default, che su browser a tutto schermo è solitamente 960px. Su browser a tutto schermo, come il browser degli smartphone, il settaggio <code>&lt;meta name="viewport" content="width=device-width"&gt;</code> fa in modo che la larghezza sarà quella del dispositivo invece di quella di default. La device-width cambia quando l'utente ruota il telefono tra modalità landscape e ritratto. Il layout viene calcolato ogni volta che un dispositivo viene ruotato o il browser viene in qualche modo ridimensionato.</p>
-
-<p>La performance della fase di layout è impattato dal numero di nodi nel DOM. La fase di layout può diventare un collo di bottiglia se richiesto durante lo scorrimento del mouse o altre animazioni. Un ritardo di 20ms al caricamento della pagina o al cambiamento di orientamento è accettabile, ma potrebbe portare a problemi se avviene durante lo scorrimento del mouse o durante animazioni. Ogni volta che l'albero di rendering è modificato, il passo di layout viene eseguito.</p>
-
-<p>Per ridurre la frequenza e durate degli eventi di layout, è consigliabile effettuare un batch degli aggiornamenti ed evitare di animare proprietà del box model.</p>
-
-<h3 id="Paint">Paint</h3>
-
-<p>L'ultimo passo è mostrare i pixel sullo schermo. Questo può avvenire quando l'albero di rendering è creato e il layout calcolato. L'intero schermo è dipinto quando la pagina viene caricata. Successivamente, solo le parti dello schermo interessate verranno ridipinte grazie alle ottimizzazioni dei browser moderni. Il tempo necessario a un repaint è solitamente molto veloce, ma è importante ricordarsi di conteggiare il tempo di layout e ripittura quando si misura il tempo richiesto da un animation frame.</p>
-
-<h2 id="Optimizing_for_CRP">Optimizing for CRP</h2>
-
-<p>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.</p>
diff --git a/files/it/web/performance/index.html b/files/it/web/performance/index.html
deleted file mode 100644
index cbcc4b1da2..0000000000
--- a/files/it/web/performance/index.html
+++ /dev/null
@@ -1,286 +0,0 @@
----
-title: Web Performance
-slug: Web/Performance
-tags:
-  - Landing
-  - NeedsTranslation
-  - Performance
-  - TopicStub
-  - Web Performance
-translation_of: Web/Performance
----
-<p><span class="seoSummary">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 </span>- is the scrolling smooth? are buttons clickable? Are pop-ups quick to open up, 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 interactive, and subjective experiences of how long it felt like it took the content to load.</p>
-
-<p>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.</p>
-
-<p>There are tools, APIs, and best practices that help us measure and improve web performance. We cover them in this section</p>
-
-<h2 id="In_this_section">In this section</h2>
-
-<p>{{LandingPageListSubpages}}</p>
-
-<div class="cleared topicpage-table">
-<div class="section">
-<h2 id="Selected_tutorials">Selected tutorials</h2>
-
-<p>The MDN <a href="/en-US/docs/Learn/Performance">Web Performance Learning Area</a> contains modern, up-to-date tutorials covering Performance essentials:</p>
-
-<dl>
- <dt><a href="/en-US/docs/Learn/Performance/What_is_web_performance">What is web performance</a></dt>
- <dd>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.</dd>
- <dt><a href="/en-US/docs/Learn/Performance/web_performance_basics">Web Performance Basics</a></dt>
- <dd>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.</dd>
- <dt><a href="/en-US/docs/Learn/Performance/perceived_performance">How do users perceive performance?</a></dt>
- <dd>
- <p>More important than how fast your website is in milliseconds, is how fast do your users perceive your site to be. Page load time, idling, responsiveness to user interaction, and the smoothness of scrolling and other animations impact these perceptions. 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.</p>
- </dd>
- <dt><a href="/en-US/docs/Learn/Performance/Multimedia">Multimedia: Images and Video</a></dt>
- <dd>Frequently, media optimization is the lowest hanging fruit of web performance. 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 images, 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.</dd>
- <dt><a href="/en-US/docs/Learn/Performance/CSS_performance">CSS performance features</a></dt>
- <dd>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.</dd>
-</dl>
-
-<dl>
-</dl>
-</div>
-
-<div class="section">
-<h2 class="Other_documentation" id="Other_documentation" name="Other_documentation">Using Performance APIs</h2>
-
-<dl>
- <dt><a href="/en-US/docs/Web/API/Performance_API/Using_the_Performance_API">Performance API</a></dt>
- <dd>This guide describes how to use the <a href="https://developer.mozilla.org/en-US/docs/Web/API/Performance" title="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."><code>Performance</code></a> interfaces that are defined in the <a class="external external-icon" href="https://w3c.github.io/hr-time/" rel="noopener">High-Resolution Time</a> standard.</dd>
- <dt><a href="/en-US/docs/Web/API/Resource_Timing_API/Using_the_Resource_Timing_API">Resource Timing API</a></dt>
- <dd><a href="/en-US/docs/Web/API/Resource_Timing_API">Resource loading and timing</a> the loading of those resources, including managing the resource buffer and coping with CORS</dd>
- <dt><a href="/en-US/docs/Web/API/Performance_Timeline/Using_Performance_Timeline">The performance timeline</a></dt>
- <dd>The <a href="/en-US/docs/Web/API/Performance_Timeline">Performance Timeline</a> standard defines extensions to the <a href="https://developer.mozilla.org/en-US/docs/Web/API/Performance" title="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."><code>Performance</code></a> interface to support client-side latency measurements within applications. Together, these interfaces can be used to help identify an application's performance bottlenecks.</dd>
- <dt><a href="/en-US/docs/Web/API/User_Timing_API/Using_the_User_Timing_API">User Timing API</a></dt>
- <dd>Create application specific timestamps using the <a href="/en-US/docs/Web/API/User_Timing_API">user timing API</a>'s "mark" and "measure" entry types - that are part of the browser's performance timeline.</dd>
- <dt><a href="/en-US/docs/Web/API/Frame_Timing_API/Using_the_Frame_Timing_API">Frame Timing API</a></dt>
- <dd>The <code><a href="/en-US/docs/Web/API/PerformanceFrameTiming">PerformanceFrameTiming</a></code> interface provides <em>frame</em> timing data about the browser's event loop.</dd>
- <dt><a href="/en-US/docs/Web/API/Beacon_API/Using_the_Beacon_API">Beacon API</a></dt>
- <dd><small>The <a href="/en-US/docs/Web/API/Beacon_API">Beacon</a> interface schedules an asynchronous and non-blocking request to a web server.</small></dd>
- <dt><a href="/en-US/docs/Web/API/Intersection_Observer_API/Timing_element_visibility">Intersection Observer API</a></dt>
- <dd>Learn to time element visibility with the <a href="https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API">Intersection Observer API</a> and be asynchronously notified when elements of interest becomes visible.</dd>
-</dl>
-
-<h2 class="Other_documentation" id="Other_documentation" name="Other_documentation">Other documentation</h2>
-
-<dl>
- <dt><a href="/en-US/docs/Tools/Performance">Developer Tools Performance Features</a></dt>
- <dd>This section provides information on how to use and understand the performance features in your developer tools, including <a href="/en-US/docs/Tools/Performance/Waterfall">Waterfall</a>, <a href="/en-US/docs/Tools/Performance/Call_Tree">Call Tree</a>, and <a href="/en-US/docs/Tools/Performance/Flame_Chart">Flame Charts</a>.</dd>
- <dt><a href="/en-US/docs/Learn/Performance/Understanding_latency">Understanding Latency</a></dt>
- <dd>Latency is the amount of time it takes between the browser making a request for a resource, and the browser receiving back the first byte of the resource requested. This article explains what latency is, how it impacts performance, how to measure latency, and how to reduce it.</dd>
-</dl>
-</div>
-</div>
-
-<h2 id="Glossary_Terms">Glossary Terms</h2>
-
-<div class="index">
-<ul class="index">
- <li>{{glossary('Beacon')}}</li>
- <li>{{glossary('Brotli compression')}}</li>
- <li>{{glossary('Client hints')}}</li>
- <li>{{glossary('Code splitting')}}</li>
- <li>{{glossary('CSSOM')}}</li>
- <li>{{glossary('Domain sharding')}}</li>
- <li>{{glossary('Effective connection type')}}</li>
- <li>{{glossary('First contentful paint')}}</li>
- <li>{{glossary('First CPU idle')}}</li>
- <li>{{glossary('First input delay')}}</li>
- <li>{{glossary('First interactive')}}</li>
- <li>{{glossary('First meaningful paint')}}</li>
- <li>{{glossary('First paint')}}</li>
- <li>{{glossary('HTTP')}}</li>
- <li>{{glossary('HTTP_2', 'HTTP/2')}}</li>
- <li>{{glossary('Jank')}}</li>
- <li>{{glossary('Latency')}}</li>
- <li>{{glossary('Lazy load')}}</li>
- <li>{{glossary('Long task')}}</li>
- <li>{{glossary('Lossless compression')}}</li>
- <li>{{glossary('Lossy compression')}}</li>
- <li>{{glossary('Main thread')}}</li>
- <li>{{glossary('Minification')}}</li>
- <li>{{glossary('Network throttling')}}</li>
- <li>{{glossary('Packet')}}</li>
- <li>{{glossary('Page load time')}}</li>
- <li>{{glossary('Page prediction')}}</li>
- <li>{{glossary('Parse')}}</li>
- <li>{{glossary('Perceived performance')}}</li>
- <li>{{glossary('Prefetch')}}</li>
- <li>{{glossary('Prerender')}}</li>
- <li>{{glossary('QUIC')}}</li>
- <li>{{glossary('RAIL')}}</li>
- <li>{{glossary('Real User Monitoring')}}</li>
- <li>{{glossary('Resource Timing')}}</li>
- <li>{{glossary('Round Trip Time (RTT)')}}</li>
- <li>{{glossary('Server Timing')}}</li>
- <li>{{glossary('Speculative parsing')}}</li>
- <li>{{glossary('Speed index')}}</li>
- <li>{{glossary('SSL')}}</li>
- <li>{{glossary('Synthetic monitoring')}}</li>
- <li>{{glossary('TCP handshake')}}</li>
- <li>{{glossary('TCP slow start')}}</li>
- <li>{{glossary('Time to first byte')}}</li>
- <li>{{glossary('Time to interactive')}}</li>
- <li>{{glossary('TLS')}}</li>
- <li>{{glossary('TCP', 'Transmission Control Protocol (TCP)')}}</li>
- <li>{{glossary('Tree shaking')}}</li>
- <li>{{glossary('Web performance')}}</li>
-</ul>
-</div>
-
-<h2 id="Documents_yet_to_be_written">Documents yet to be written</h2>
-
-<dl>
- <dt><a href="/en-US/docs/Learn/Performance/JavaScript">JavaScript performance best practices</a></dt>
- <dd>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. <span class="veryhardreadability"><span><span>This article outlines some JavaScript best practices that can ensure even complex content is as performant as possible.</span></span></span></dd>
- <dt><a href="/en-US/docs/Learn/Performance/Mobile">Mobile performance</a></dt>
- <dd>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.</dd>
- <dt>Performance bottlenecks</dt>
- <dd></dd>
- <dt>Understanding bandwidth</dt>
- <dd>
- <div>
- <div class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr"><span><span>Bandwidth is the amount of data (measured in Mbps or Kbps) that one can send per second. </span></span><span class="veryhardreadability"><span><span>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</span></span></span><span><span>.</span></span></div>
- </div>
- </dd>
- <dt><a href="/en-US/docs/Learn/Performance/HTTP2">HTTP/2 and you</a></dt>
- <dd>
- <p>The transport layer—that is, HTTP—is utterly essential to the functioning of the web, and it has only been relatively recently that it has seen a major update in the form of HTTP/2. Out of the box, HTTP/2 provides many performance improvements and advantages over its predecessor, but it also changes the landscape. In this article, you'll learn what HTTP/2 does for you, and how to fine-tune your application to make it do go even further.</p>
- </dd>
- <dt>The role of TLS in performance</dt>
- <dd>
- <p>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.</p>
- </dd>
- <dt>Reading performance charts</dt>
- <dd>Developer tools provide information on performance, memory, and network requests. Knowing how to read <a href="https://developer.mozilla.org/en-US/docs/Tools/Performance/Waterfall">waterfall</a> charts, <a href="https://developer.mozilla.org/en-US/docs/Tools/Performance/Call_Tree">call trees</a>, traces, <a href="https://developer.mozilla.org/en-US/docs/Tools/Performance/Flame_Chart">flame charts</a> , and <a href="https://developer.mozilla.org/en-US/docs/Tools/Performance/Allocations">allocations</a> in your browser developer tools will help you understand waterfall and flame charts in other performance tools.</dd>
- <dt>Analyzing JavaScript bundles</dt>
- <dd>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. <span class="veryhardreadability"><span><span>In this guide, we'll show you how to analyze your application's script bundles, so you know </span></span><em><span>what</span></em><span><span> you're using, as well how to detect if your app contains duplicated scripts between bundles</span></span></span><span><span>.</span></span></dd>
- <dt><a href="/en-US/docs/Web/Performance/Lazy_loading">Lazy loading</a></dt>
- <dd>It isn't always necessary to load all of a web applications assets on initial page load. Lazy Loading is defering the loading of assets on a page, such as scripts, images, etc., on a page to a later point in time – when those assets are actually needed.</dd>
- <dt>Lazy-loading JavaScript with import()</dt>
- <dd>The term "lazy loading" often refers to load deferment techniques for assets not needed at load such as loading below-the-fold imagery only when those images scroll into the view. Now there are native features to load JavaScript! In this guide, we'll talk about the dynamic import() statement, a newer browser feature, that loads a JavaScript module on demand.</dd>
- <dt><a href="/en-US/docs/Web/Performance/Controlling_resource_delivery_with_resource_hints">Controlling resource delivery with resource hints</a></dt>
- <dd>Browsers often know better than we do when it comes to resource prioritization and delivery—but 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.</dd>
- <dt><a href="/en-US/docs/Web/Performance/Performance_budget">Performance Budgets</a></dt>
- <dd>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. </dd>
- <dt><a href="/en-US/docs/Web/Performance/Checklist">Web performance checklist</a></dt>
- <dd>A performance checklist of features to consider when developing applications with links to tutorials on how to implement each features, include service workers, diagnosing performance problems, font loading best practices, client hints, creating performant animations, etc.</dd>
- <dt><a href="/en-US/docs/Web/Performance/Mobile_performance_checklist">Mobile performance checklist</a></dt>
- <dd>A concise checklist of performance considerations impacting mobile network users on hand-held, battery operated devices.</dd>
-</dl>
-
-<h3 id="App_Performance">App Performance</h3>
-
-<dl>
- <dt><a href="/en-US/Apps/Developing/Performance/Performance_fundamentals">Performance fundamentals</a></dt>
- <dd>A wide overview of Web application performance, what it is, how the browser helps to improve it, and what tools and processes you can use to test and further improve it.</dd>
- <dt><a href="/en-US/Apps/Developing/Performance/Optimizing_startup_performance">Optimizing startup performance</a></dt>
- <dd>Tips and suggestions to help you improve startup performance, both when writing a new app and when porting an app from another platform to the Web.</dd>
- <dt><a href="/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler">Profiling with the built-in profiler</a></dt>
- <dd>Learn how to profile app performance with Firefox's built-in profiler.</dd>
- <dt><a href="/en-US/Apps/Build/Performance/CSS_JavaScript_animation_performance">CSS and JavaScript animation performance</a></dt>
- <dd>Animations are critical for a pleasurable user experience. This article discusses the performance differences between CSS- and JavaScript-based animations. </dd>
-</dl>
-
-<p><span class="alllinks"><a href="/en-US/docs/tag/Performance">View all articles about performance...</a></span></p>
-
-<h2 id="See_also">See also</h2>
-
-<p>HTML</p>
-
-<ul>
- <li><a href="/en-US/docs/Web/HTML/Element/picture">The <code>&lt;picture&gt;</code> Element</a></li>
- <li><a href="/en-US/docs/Web/HTML/Element/video">The <code>&lt;video&gt;</code> Element</a></li>
- <li><a href="/en-US/docs/Web/HTML/Element/source">The <code>&lt;source&gt;</code> Element</a></li>
- <li><a href="/en-US/docs/Web/HTML/Element/img#Attributes">The <code>&lt;img&gt; srcset</code> attribute</a>
-  <ul>
-   <li><a href="/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images">Responsive images</a></li>
-  </ul>
- </li>
- <li><a href="/en-US/docs/Web/HTML/Preloading_content">Preloading content with <code>rel="preload"</code></a> - <a href="https://w3c.github.io/preload/">(https://w3c.github.io/preload/ </a>)</li>
-</ul>
-
-<p>CSS</p>
-
-<ul>
- <li><a href="/en-US/docs/Web/CSS/will-change">will-change</a></li>
- <li>GPU v CPU</li>
- <li>Measuring layout</li>
- <li>font-loading best practices</li>
-</ul>
-
-<p>JavaScript</p>
-
-<ul>
- <li><a href="/en-US/docs/Web/Events/DOMContentLoaded">DOMContentLoaded</a></li>
- <li><a href="/en-US/docs/Glossary/Garbage_collection">Garbage collection</a></li>
- <li><a href="/en-US/docs/Web/API/window/requestAnimationFrame">requestAnimationFrame</a></li>
-</ul>
-
-<p>APIs</p>
-
-<ul>
- <li><a href="/en-US/docs/Web/API/Performance_API">Performance API</a></li>
- <li><a href="/en-US/docs/Web/API/Navigation_timing_API">Navigation Timing API</a></li>
- <li><a href="/en-US/docs/Web/API/Media_Capabilities_API/Using_the_Media_Capabilities_API">Media Capabilities API</a></li>
- <li><a href="/en-US/docs/Web/API/Network_Information_API">Network Information API</a></li>
- <li><a href="/en-US/docs/Web/API/PerformanceNavigationTiming">PerformanceNavigationTiming</a></li>
- <li><a href="/en-US/docs/Web/API/Battery_Status_API">Battery Status API</a></li>
- <li><a href="/en-US/docs/Web/API/Navigator/deviceMemory">Navigator.deviceMemory</a></li>
- <li><a href="/en-US/docs/Web/API/Intersection_Observer_API">Intersection Observer</a></li>
- <li><a href="/en-US/docs/Web/API/User_Timing_API/Using_the_User_Timing_API">Using the User Timing AP</a>I</li>
- <li><a href="/en-US/docs/Web/API/Long_Tasks_API">Long Tasks API</a></li>
- <li><a href="/en-US/docs/Web/API/DOMHighResTimeStamp">High Resolution Timing API</a> (<a href="https://w3c.github.io/hr-time/">https://w3c.github.io/hr-time/)</a></li>
- <li><a href="/en-US/docs/Web/API/Resource_Timing_API/Using_the_Resource_Timing_API">Resource Timing API</a></li>
- <li><a href="/en-US/docs/Web/API/Page_Visibility_API">Page Visibility</a></li>
- <li><a href="/en-US/docs/Web/API/Background_Tasks_API">Cooperative Scheduling of Background Tasks API</a>
-  <ul>
-   <li style="margin-top: 0.25em;"><a href="/en-US/docs/Web/API/Window/requestIdleCallback">requestIdleCallback() </a></li>
-  </ul>
- </li>
- <li><a href="/en-US/docs/Web/API/Beacon_API/Using_the_Beacon_API">Beacon API</a></li>
- <li>Resource Hints - <a href="/en-US/docs/Web/HTTP/Headers/X-DNS-Prefetch-Control">dns-prefetch</a>, preconnect, <a href="/en-US/docs/Web/HTTP/Link_prefetching_FAQ">prefetch</a>, and prerender</li>
- <li><a href="/en-US/docs/Web/API/FetchEvent/navigationPreload">Fetchevent.navigationPreload</a></li>
- <li><a href="/en-US/docs/Web/API/PerformanceServerTiming">Performance Server Timing API</a></li>
-</ul>
-
-<p>Headers</p>
-
-<ul>
- <li><a href="/en-US/docs/Web/HTTP/Headers/Content-Encoding">Content-encoding</a></li>
- <li>HTTP/2</li>
- <li><a href="/en-US/docs/Glossary/GZip_compression">gZip</a></li>
- <li>Client Hints</li>
-</ul>
-
-<p>Tools</p>
-
-<ul>
- <li><a href="/en-US/docs/Tools/Performance">Performance in Firefox Developer Tools</a></li>
- <li>Flame charts</li>
- <li>the Network panel</li>
- <li>waterfall charts</li>
-</ul>
-
-<p>Additional Metrics</p>
-
-<ul>
- <li>Speed Index and Perceptual Speed Index</li>
-</ul>
-
-<p>Best Practices</p>
-
-<ul>
- <li><a href="/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers">Using Service Workers</a></li>
- <li><a href="/en-US/docs/Web/API/Web_Workers_API/Using_web_workers">Using Web Workers</a>
-  <ul>
-   <li><a href="/en-US/docs/Web/API/Web_Workers_API">Web Workers API</a></li>
-  </ul>
- </li>
- <li><a href="/en-US/docs/Web/Apps/Progressive/Offline_Service_workers">PWA</a></li>
- <li><a href="/en-US/docs/Web/HTTP/Caching">Caching</a></li>
- <li>Content Delivery Networks (CDN)</li>
-</ul>