diff options
| author | Peter Bengtsson <mail@peterbe.com> | 2020-12-08 14:41:45 -0500 |
|---|---|---|
| committer | Peter Bengtsson <mail@peterbe.com> | 2020-12-08 14:41:45 -0500 |
| commit | 1109132f09d75da9a28b649c7677bb6ce07c40c0 (patch) | |
| tree | 0dd8b084480983cf9f9680e8aedb92782a921b13 /files/es/web/performance | |
| parent | 4b1a9203c547c019fc5398082ae19a3f3d4c3efe (diff) | |
| download | translated-content-1109132f09d75da9a28b649c7677bb6ce07c40c0.tar.gz translated-content-1109132f09d75da9a28b649c7677bb6ce07c40c0.tar.bz2 translated-content-1109132f09d75da9a28b649c7677bb6ce07c40c0.zip | |
initial commit
Diffstat (limited to 'files/es/web/performance')
| -rw-r--r-- | files/es/web/performance/fundamentals/index.html | 233 | ||||
| -rw-r--r-- | files/es/web/performance/how_browsers_work/index.html | 208 | ||||
| -rw-r--r-- | files/es/web/performance/index.html | 242 | ||||
| -rw-r--r-- | files/es/web/performance/mejorando_rendimienot_inicial/index.html | 95 |
4 files changed, 778 insertions, 0 deletions
diff --git a/files/es/web/performance/fundamentals/index.html b/files/es/web/performance/fundamentals/index.html new file mode 100644 index 0000000000..4d5fa5378c --- /dev/null +++ b/files/es/web/performance/fundamentals/index.html @@ -0,0 +1,233 @@ +--- +title: Performance fundamentals +slug: Web/Performance/Fundamentals +translation_of: Web/Performance/Fundamentals +--- +<div class="summary"> +<p>Performance significa eficiencia. En el contexto de Open Web Apps, este documento explica en general qué es performance, cómo la plataforma del navegador ayuda a mejorarlo y qué herramientas y procesos puede usar para probarlo y mejorarlo.</p> +</div> + +<h2 id="¿Qué_es_performance">¿Qué es performance?</h2> + +<p>En última instancia, el performance percibido por el usuario es el único performance que importa. Los usuarios proporcionan entradas al sistema a través del tacto, el movimiento y el habla. A cambio, reciben salidas a través de la vista, el tacto y la audición. El performance es la calidad de las salidas del sistema en respuesta a las entradas del usuario.</p> + +<p>En igualdad de condiciones, el código optimizado para algún objetivo diferente al performance percibido por el usuario (en adelante, PPU) pierde cuando compite contra código optimizado para PPU. Los usuarios prefieren una aplicación fluida y receptiva que capaz de procesar 1,000 transacciones de base de datos por segundo, en lugar de una aplicación que no responde aún cuando sea capaz de procesar 100,000,000 por segundo. Esto no quiere decir, que no es importante optimizar otras métricas, pero se debe trabajar con PPU como objetivo principal.</p> + +<p>Las siguientes secciones señalan y discuten métricas esenciales para medir performance.</p> + +<h3 id="Capacidad_de_respuesta">Capacidad de respuesta</h3> + +<p> </p> + +<p>La capacidad de respuesta simplemente significa la rapidez con la que el sistema proporciona salidas (posiblemente varias) en respuesta a las entradas del usuario. Por ejemplo, cuando un usuario toca la pantalla, espera que los píxeles cambien de cierta manera. Para esta interacción, la métrica de capacidad de respuesta es el tiempo transcurrido entre el toque y el cambio de píxel.</p> + +<p>La capacidad de respuesta a veces implica múltiples etapas de retroalimentación. El lanzamiento de la aplicación es un caso particularmente importante que se analiza con más detalle a continuación.</p> + +<p>La capacidad de respuesta es importante simplemente porque las personas se sienten frustradas y enojadas cuando son ignoradas. Una aplicación está ignorando al usuario cada segundo que no responde a la entrada del usuario.</p> + +<p> </p> + +<h3 id="Frecuencia_de_cuadros">Frecuencia de cuadros</h3> + +<p> </p> + +<p>La frecuencia de cuadros es la velocidad a la que el sistema cambia los píxeles que se muestran al usuario. Este es un concepto familiar: todos prefieren, digamos, juegos que muestran 60 cuadros por segundo sobre los que muestran 10 cuadros por segundo, incluso si no pueden explicar por qué.</p> + +<p>La velocidad de cuadros es importante como una métrica de "calidad de servicio". Las pantallas de computadora están diseñadas para "engañar" la vista del usuario, al entregarles fotones que imitan la realidad. Por ejemplo, el papel cubierto con texto impreso refleja fotones a los ojos del usuario formando un patrón. Al manipular los píxeles, una aplicación de lectura emite fotones en un patrón similar para "engañar" la vista del usuario.</p> + +<p>El cerebro entonces infiere que el moviemiento se "actualiza" de manera fluida y continua. (Las luces estroboscópicas son divertidas porque dan la vuelta al revés, lo que confunde al cerebro el cual reacciona generando adrenalina y altos niveles de estrés). En una pantalla de computadora, una mayor tasa de cuadros simplemente hace una imitación más fiel de la realidad.</p> + +<p> </p> + +<div class="note"> +<p><strong>Nota</strong>: Los seres humanos generalmente no pueden percibir diferencias en la frecuencia de cuadros por encima de 60Hz. Es por eso que las pantallas electrónicas más modernas están diseñadas para actualizarse a esa velocidad. Una televisión probablemente se ve entrecortada y poco realista para un colibrí, por ejemplo.</p> +</div> + +<h3 id="Uso_de_la_memoria">Uso de la memoria</h3> + +<p>El <strong>uso de la memoria</strong> <span class="tlid-translation translation" lang="es"><span title=""> es otra métrica clave.</span> <span title="">A diferencia de la capacidad de respuesta y la frecuencia de cuadros, los usuarios no perciben directamente el uso de la memoria, pero el uso de la memoria se aproxima mucho al "estado del usuario".</span> <span title="">Un sistema ideal mantendría el 100% del estado del usuario en todo momento: todas las aplicaciones en el sistema se ejecutarían simultáneamente, y todas las aplicaciones conservarían el estado creado por el usuario la última vez que el usuario interactuó con la aplicación (el estado de la aplicación se almacena en la memoria de la computadora</span><span title="">, por lo que la aproximación es cercana).</span></span></p> + +<p>De esto viene un corolario importante pero contraintuitivo: un sistema bien diseñado no maximiza la cantidad de memoria <strong>libre</strong>. La memoria es un recurso, y la memoria libre es un recurso no utilizado. Más bien, un sistema bien diseñado se ha optimizado para <strong>usar </strong>la mayor cantidad de memoria posible para mantener el estado del usuario, al mismo tiempo que cumple otros objetivos de PPU.</p> + +<p>Eso no significa que el sistema deba <strong>desperdiciar</strong> memoria. Cuando un sistema usa más memoria de la necesaria para mantener un estado particular del usuario, el sistema está desperdiciando un recurso que podría usar para retener algún otro estado del usuario. En la práctica, ningún sistema puede mantener todos los estados del usuario. La asignación inteligente de memoria al estado del usuario es una preocupación importante que veremos más detalladamente a continuación.</p> + +<h3 id="Consumo_de_energía">Consumo de energía</h3> + +<p> </p> + +<p>La métrica final discutida aquí es el consumo de energía. Al igual que el uso de la memoria, los usuarios perciben el consumo de energía solo indirectamente, por el tiempo que sus dispositivos pueden mantener todos los demás objetivos de PPU. Para cumplir los objetivos de PPU, el sistema debe utilizar solo la potencia mínima requerida.</p> + +<p>El resto de este documento analizará el rendimiento en términos de estas métricas.</p> + +<p> </p> + +<h2 id="Optimizaciones_de_rendimiento_según_la_plataforma">Optimizaciones de rendimiento según la plataforma</h2> + +<p>Esta sección proporciona una breve descripción de cómo Firefox / Gecko contribuye al rendimiento en general, desde un nivel más abajo que las aplicaciones. Desde la perspectiva de un desarrollador o un usuario, esto responde a la pregunta "¿Qué hace la plataforma por usted?"</p> + +<h3 id="Tecnologías_web">Tecnologías web</h3> + +<p>La plataforma web proporciona muchas herramientas, algunas más adecuadas para trabajos particulares que otras. Toda la lógica de la aplicación está escrita en JavaScript. Para mostrar gráficos, los desarrolladores pueden usar HTML o CSS (es decir, lenguajes declarativos de alto nivel), o usar interfaces imperativas de bajo nivel ofrecidas por el elemento <a href="/es/docs/Web/HTML/Elemento/canvas"><canvas></a> (que incluye <a href="/es/docs/Web/API/WebGL_API">WebGL</a>). En algún lugar "entre" HTML / CSS y Canvas está <a href="/es/docs/Web/SVG">SVG</a>, que ofrece algunos beneficios de ambos.</p> + +<p>HTML y CSS aumentan en gran medida la productividad, a veces a expensas de la frecuencia de cuadros o el control a nivel de píxeles de la renderización. El texto y las imágenes se vuelven a generar automáticamente, los elementos de la IU reciben automáticamente el tema del sistema, y el sistema proporciona soporte "integrado" para algunos casos de uso que los desarrolladores pueden no pensar inicialmente, como pantallas de diferente resolución o idiomas de derecha a izquierda.</p> + +<p>The <code>canvas</code> element offers a pixel buffer directly for developers to draw on. This gives developers pixel-level control over rendering and precise control of framerate, but now the developers need to deal with multiple resolutions and orientations, right-to-left languages, and so forth. Developers draw to canvases using either a familiar 2D drawing API, or WebGL, a "close to the metal" binding that mostly follows OpenGL ES 2.0.</p> + +<div class="note"> +<p><strong>Note</strong>: Firefox OS is optimized for apps built with Web technologies: <a href="/en-US/docs/Web/HTML">HTML</a>, <a href="/en-US/docs/Web/CSS">CSS</a>, <a href="/en-US/docs/Web/JavaScript">JavaScript</a>, and so on. Except for a handful of basic system services, all code that runs in Firefox OS comes from Web apps and the Gecko engine. Even the OS window manager is written in HTML, CSS, and JavaScript. Because the core operating system and applications are built with same Web technologies, it's critical how those technologies perform. There's no "escape hatch". This greatly benefits developers because now third-party apps benefit from all the OS's own optimizations. There's no "magic performance sauce" available only to preinstalled code. See <a href="/en-US/Apps/Developing/Performance/Firefox_OS_performance_testing">Firefox OS performance testing</a> for more details relevant to Firefox OS.</p> +</div> + +<h3 id="Gecko_rendering">Gecko rendering</h3> + +<p>The Gecko JavaScript engine supports just-in-time (JIT) compilation. This enables application logic to perform comparably to other virtual machines — such as Java virtual machines — and in some cases even close to "native code".</p> + +<p>The graphics pipeline in Gecko that underpins HTML, CSS, and Canvas is optimized in several ways. The HTML/CSS layout and graphics code in Gecko reduces invalidation and repainting for common cases like scrolling; developers get this support "for free". Pixel buffers painted by both Gecko "automatically" and applications to <code>canvas</code> "manually" minimize copies when being drawn to the display framebuffer. This is done by avoiding intermediate surfaces where they would create overhead (such as per-application "back buffers" in many other operating systems), and by using special memory for graphics buffers that can be directly accessed by the compositor hardware. Complex scenes are rendered using the device's GPU for maximum performance. To improve power usage, simple scenes are rendered using special dedicated composition hardware, while the GPU idles or turns off.</p> + +<p>Fully static content is the exception rather than the rule for rich applications. Rich applications use dynamic content with {{ cssxref("animation") }} and {{ cssxref ("transition") }} effects. Transitions and animations are particularly important to applications: developers can use CSS to declare complicated behaviour with a simple, high-level syntax. In turn, Gecko's graphics pipeline is highly optimized to render common animations efficiently. Common-case animations are "offloaded" to the system compositor, which can render them in a performant, power-efficient fashion.</p> + +<p>An app's startup performance matters just as much as its runtime performance. Gecko is optimized to load a wide variety of content efficiently: the entire Web! Many years of improvements targeting this content, like parallel HTML parsing, intelligent scheduling of reflows and image decoding, clever layout algorithms, etc., translate just as well to improving Web applications on Firefox.</p> + +<div class="note"> +<p><strong>Note</strong>: See <a href="/en-US/Apps/Developing/Performance/Firefox_OS_performance_testing">Firefox OS performance testing</a> for more information about Firefox OS specifics that help to further improve startup performance.</p> +</div> + +<h2 id="Application_performance">Application performance</h2> + +<p>This section is intended for developers asking the question: "How can I make my app fast"?</p> + +<h3 id="Startup_performance">Startup performance</h3> + +<p>Application startup is punctuated by three user-perceived events, generally speaking:</p> + +<ul> + <li>The first is the application <strong>first paint</strong> — the point at which sufficient application resources have been loaded to paint an initial frame</li> + <li>The second is when the application becomes <strong>interactive</strong> — for example, users are able to tap a button and the application responds</li> + <li>The final event is <strong>full load</strong> — for example when all the user's albums have been listed in a music player</li> +</ul> + +<p>The key to fast startup is to keep two things in mind: UPP is all that matters, and there's a "critical path" to each user-perceived event above. The critical path is exactly and only the code that must run to produce the event.</p> + +<p>For example, to paint an application's first frame that comprises visually some HTML and CSS to style that HTML:</p> + +<ol> + <li>The HTML must be parsed</li> + <li>The DOM for that HTML must be constructed</li> + <li>Resources like images in that part of the DOM have to be loaded and decoded</li> + <li>The CSS styles must be applied to that DOM</li> + <li>The styled document has to be reflowed</li> +</ol> + +<p>Nowhere in that list is "load the JS file needed for an uncommon menu"; "fetch and decode the image for the High Scores list", etc. Those work items are not on the critical path to painting the first frame.</p> + +<p>It seems obvious, but to reach a user-perceived startup event more quickly, the main "trick" is run <em>only the code on the critical path.</em> Shorten the critical path by simplifying the scene.</p> + +<p>The Web platform is highly dynamic. JavaScript is a dynamically-typed language, and the Web platform allows loading code, HTML, CSS, images, and other resources dynamically. These features can be used to defer work that's off the critical path by loading unnecessary content "lazily" some time after startup.</p> + +<p>Another problem that can delay startup is idle time, caused by waiting for responses to requests (like database loads). To avoid this problem, applications should issue requests as early as possible in startup (this is called "front-loading"). Then when the data is needed later, hopefully it's already available and the application doesn't have to wait.</p> + +<div class="note"> +<p><strong>Note</strong>: For much more information on improving startup performance, read <a href="/en-US/Apps/Developing/Performance/Optimizing_startup_performance">Optimizing startup performance</a>.</p> +</div> + +<p>On the same note, notice that locally-cached, static resources can be loaded much faster than dynamic data fetched over high-latency, low-bandwidth mobile networks. Network requests should never be on the critical path to early application startup. Caching resources locally is also the only way applications can be used offline, and for standard Open Web Apps, at the moment this requires use of HTML5 <a href="/en-US/docs/HTML/Using_the_application_cache">AppCache</a>.</p> + +<div class="note"> +<p><strong>Note</strong>: Firefox OS allows applications to cache resources by being installed as applications, either being "packaged" in a compressed ZIP file or "hosted" through HTML5 <a href="/en-US/docs/HTML/Using_the_application_cache">AppCache</a>. How to choose between these options for a particular type of application is beyond the scope of this document, but in general application packages provide optimal load performance; AppCache is slower. Installable apps will hopefully be coming to other platforms soon!</p> +</div> + +<h3 id="Framerate">Framerate</h3> + +<p>The first important thing for high framerate is to choose the right tool. Use HTML and CSS to implement content that's mostly static, scrolled, and infrequently animated. Use Canvas to implement highly dynamic content, like games that need tight control over rendering and don't need theming.</p> + +<p>For content drawn using Canvas, it's up to the developer to hit framerate targets: they have direct control over what's drawn.</p> + +<p>For HTML and CSS content, the path to high framerate is to use the right primitives. Firefox is highly optimized to scroll arbitrary content; this is usually not a concern. But often trading some generality and quality for speed, such as using a static rendering instead of a CSS radial gradient, can push scrolling framerate over a target. CSS <a href="/en-US/docs/Web/Guide/CSS/Media_queries">media queries</a> allow these compromises to be restricted only to devices that need them.</p> + +<p>Many applications use transitions or animations through "pages", or "panels". For example, the user taps a "Settings" button to transition into an application configuration screen, or a settings menu "pops up". Firefox is highly optimized to transition and animate scenes that:</p> + +<ul> + <li>use pages/panels approximately the size of the device screen or smaller</li> + <li>transition/animate the CSS <code>transform</code> and <code>opacity</code> properties</li> +</ul> + +<p>Transitions and animations that adhere to these guidelines can be offloaded to the system compositor and run maximally efficiently.</p> + +<h3 id="Memory_and_power_usage">Memory and power usage</h3> + +<p>Improving memory and power usage is a similar problem to speeding up startup: don't do unneeded work or lazily load uncommonly-used UI resources. Do use efficient data structures and ensure resources like images are optimized well.</p> + +<p>Modern CPUs can enter a lower-power mode when mostly idle. Applications that constantly fire timers or keep unnecessary animations running prevent CPUs from entering low-power mode. Power-efficient applications shouldn't do that.</p> + +<p>When applications are sent to the background, a {{event("visibilitychange")}} event is fired on their documents. This event is a developer's friend; applications should listen for it. Applications that drop as many loaded resources as possible when sent to the background use less memory and are less likely discarded, in the case of Firefox OS (see the note below). This in turn means they "start up" faster (since they are already running) and have better UPP.</p> + +<div class="note"> +<p><strong>Note</strong>: As mentioned above, Firefox OS tries to keep as many applications running simultaneously as it can, but does have to discard applications sometimes, usually when the device runs out of memory. To find out more about how Firefox OS manages memory usage and kills apps when out of memory issues are encountered, read <a href="/en-US/Firefox_OS/Debugging/Debugging_OOMs">Debugging out of memory errors on Firefox OS</a>.</p> +</div> + +<h3 id="Specific_coding_tips_for_application_performance">Specific coding tips for application performance</h3> + +<p>The following practical tips will help improve one or more of the Application performance factors discussed above.</p> + +<h4 id="Use_CSS_animations_and_transitions">Use CSS animations and transitions</h4> + +<p>Instead of using some library’s <code>animate()</code> function, which probably currently uses many badly performing technologies ({{domxref("window.setTimeout()")}} or <code>top</code>/<code>left</code> positioning, for example) use <a href="/en-US/docs/Web/Guide/CSS/Using_CSS_animations">CSS animations</a>. In many cases, you can actually use <a href="/en-US/docs/Web/Guide/CSS/Using_CSS_transitions">CSS Transitions</a> to get the job done. This works well because the browser is designed to optimize these effects and use the GPU to handle them smoothly with minimal impact on processor performance. Another benefit is that you can define these effects in CSS along with the rest of your app's look-and-feel, using a standardized syntax.</p> + +<p>CSS animations give you very granular control over your effects using <a href="/en-US/docs/Web/CSS/@keyframes">keyframes</a>, and you can even watch events fired during the animation process in order to handle other tasks that need to be performed at set points in the animation process. You can easily trigger these animations with the {{cssxref(":hover")}}, {{cssxref(":focus")}}, or {{cssxref(":target")}}, or by dynamically adding and removing classes on parent elements.</p> + +<p>If you want to create animations on the fly or modify them in <a href="/en-US/docs/JavaScript">JavaScript</a>, James Long has written a simple library for that called <a href="https://github.com/jlongster/css-animations.js/">CSS-animations.js</a>.</p> + +<h4 id="Use_CSS_transforms">Use CSS transforms</h4> + +<p>Instead of tweaking absolute positioning and fiddling with all that math yourself, use the {{cssxref("transform")}} CSS property to adjust the position, scale, and so forth of your content. The reason is, once again, hardware acceleration. The browser can do these tasks on your GPU, letting the CPU handle other things.</p> + +<p>In addition, transforms give you capabilities you might not otherwise have. Not only can you translate elements in 2D space, but you can transform in three dimensions, skew and rotate, and so forth. Paul Irish has an <a href="http://paulirish.com/2012/why-moving-elements-with-translate-is-better-than-posabs-topleft/">in-depth analysis of the benefits of <code>translate()</code></a> from a performance point of view. In general, however, you have the same benefits you get from using CSS animations: you use the right tool for the job and leave the optimization to the browser. You also use an easily extensible way of positioning elements — something that needs a lot of extra code if you simulate translation with <code>top</code> and <code>left</code> positioning. Another bonus is that this is just like working in a <code>canvas</code> element.</p> + +<div class="note"> +<p><strong>Note</strong>: You may need to attach a <code>translateZ(0.1)</code> transform if you wish to get hardware acceleration on your CSS animations, depending on platform. As noted above, this can improve performance, but can also have memory consumption issues. What you do in this regard is up to you — do some testing and find out what's best for your particular app.</p> +</div> + +<h4 id="Use_requestAnimationFrame()_instead_of_setInterval()">Use <code>requestAnimationFrame()</code> instead of <code>setInterval()</code></h4> + +<p>Calls to {{domxref("window.setInterval()")}} run code at a presumed frame rate that may or may not be possible under current circumstances. It tells the browser to render results even while the browser isn't actually drawing; that is, while the video hardware hasn't reached the next display cycle. This wastes processor time and can even lead to reduced battery life on the user's device.</p> + +<p>Instead, you should try to use {{domxref("window.requestAnimationFrame()")}}. This waits until the browser is actually ready to start building the next frame of your animation, and won't bother if the hardware isn't going to actually draw anything. Another benefit to this API is that animations won't run while your app isn't visible on the screen (such as if it's in the background and some other task is operating). This will save battery life and prevent users from cursing your name into the night sky.</p> + +<h4 id="Make_events_immediate">Make events immediate</h4> + +<p>As old-school, accessibility-aware Web developers we love click events since they also support keyboard input. On mobile devices, these are too slow. You should use {{event("touchstart")}} and {{event("touchend")}} instead. The reason is that these don’t have a delay that makes the interaction with the app appear sluggish. If you test for touch support first, you don’t sacrifice accessibility, either. For example, the Financial Times uses a library called <a href="https://github.com/ftlabs/fastclick">fastclick</a> for that purpose, which is available for you to use.</p> + +<h4 id="Keep_your_interface_simple">Keep your interface simple</h4> + +<p>One big performance issue we found in HTML5 apps was that moving lots of <a href="/en-US/docs/DOM">DOM</a> elements around makes everything sluggish — especially when they feature lots of gradients and drop shadows. It helps a lot to simplify your look-and-feel and move a proxy element around when you drag and drop.</p> + +<p>When, for example, you have a long list of elements (let’s say tweets), don’t move them all. Instead, keep in your DOM tree only the ones that are visible and a few on either side of the currently visible set of tweets. Hide or remove the rest. Keeping the data in a JavaScript object instead of accessing the DOM can vastly improve your app's performance. Think of the display as a presentation of your data rather than the data itself. That doesn’t mean you can't use straight HTML as the source; just read it once and then scroll 10 elements, changing the content of the first and last accordingly to your position in the results list, instead of moving 100 elements that aren’t visible. The same trick applies in games to sprites: if they aren’t currently on the screen, there is no need to poll them. Instead re-use elements that scroll off screen as new ones coming in.</p> + +<h2 id="General_application_performance_analysis">General application performance analysis</h2> + +<p>Firefox, Chrome, and other browsers include built-in tools that can help you diagnose slow page rendering. In particular, <a href="/en-US/docs/Tools/Network_Monitor">Firefox's Network Monitor</a> will display a precise timeline of when each network request on your page happens, how large it is, and how long it takes.</p> + +<p><img alt="The Firefox network monitor showing get requests, multiple files, and different times taken to load each resource on a graph." src="https://mdn.mozillademos.org/files/6845/network-monitor.jpg" style="display: block; height: 713px; margin: 0px auto; width: 700px;"></p> + +<p>If your page contains JavaScript code that is taking a long time to run, the <a href="/en-US/docs/Tools/Profiler">JavaScript profiler</a> will pinpoint the slowest lines of code:</p> + +<p><img alt="The Firefox JavaScript profiler showing a completed profile 1." src="https://mdn.mozillademos.org/files/6839/javascript-profiler.png" style="display: block; height: 433px; margin: 0px auto; width: 896px;"></p> + +<p>The <a href="/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler">Built-in Gecko Profiler</a> is a very useful tool that provides even more detailed information about which parts of the browser code are running slowly while the profiler runs. This is a bit more complex to use, but provides a lot of useful details.</p> + +<p><img alt="A built-in Gecko profiler windows showing a lot of network information." src="https://mdn.mozillademos.org/files/6837/gecko-profiler.png" style="display: block; height: 514px; margin: 0px auto; width: 896px;"></p> + +<div class="note"> +<p><strong>Note</strong>: You can use these tools with the Android browser by running Firefox and enabling <a href="/en-US/docs/Tools/Remote_Debugging">remote debugging</a>.</p> +</div> + +<p>Using <a href="https://addons.mozilla.org/en-US/firefox/addon/yslow/">YSlow</a> (which requires <a href="https://getfirebug.com/">Firebug</a>) provides extremely helpful recommendations for improving performance. Many of the identified problems and suggested solutions are especially useful for mobile browsers. You should definitely run YSlow and follow its recommendations.</p> + +<p><img alt="A YSlow window showing a set of tips for improving performance, the top one being make fewer http requests." src="https://mdn.mozillademos.org/files/6843/yslow.png" style="display: block; height: 240px; margin: 0px auto; width: 605px;"></p> + +<p>In particular, making dozens or hundreds of network requests takes longer in mobile browsers. Rendering large images and CSS gradients can also take longer. Simply downloading large files can take longer, even over a fast network, because mobile hardware is sometimes too slow to take advantage of all the available bandwidth. For useful general tips on mobile Web performance, have a look at Maximiliano Firtman's <a href="http://www.slideshare.net/firt/mobile-web-high-performance">Mobile Web High Performance</a> talk.</p> + +<h3 id="Testcases_and_submitting_bugs">Testcases and submitting bugs</h3> + +<p>If the Firefox and Chrome developer tools don't help you find a problem, or if they seem to indicate that the Web browser has caused the problem, try to provide a reduced test case that maximally isolates the problem. That often helps in diagnosing problems.</p> + +<p>See if you can reproduce the problem by saving and loading a static copy of an HTML page (including any images/stylesheets/scripts it embeds). If so, edit the static files to remove any private information, then send them to others for help (submit a <a href="https://bugzilla.mozilla.org/">Bugzilla</a> report, for example, or host it on a server and share the URL). You should also share any profiling information you've collected using the tools listed above.</p> diff --git a/files/es/web/performance/how_browsers_work/index.html b/files/es/web/performance/how_browsers_work/index.html new file mode 100644 index 0000000000..95677a1f2d --- /dev/null +++ b/files/es/web/performance/how_browsers_work/index.html @@ -0,0 +1,208 @@ +--- +title: 'Populating the page: how browsers work' +slug: Web/Performance/How_browsers_work +tags: + - Composición + - Navegadorres + - Renderizado +translation_of: Web/Performance/How_browsers_work +--- +<p>Los usuarios quieren que las experiencias en la web sean rápidas y que tengan una intereacción sencilla. Por este motivo, los desarrolladores debén esforzarse para lograr estos dos objetivos</p> + +<p>Para entender como mejorar el desempeño, es importante entender como funciona el navegador.</p> + +<p>Overview</p> + +<p>Fast sites provide better user experiences. Users want and expect web experiences with content that is fast to load and smooth to interact with.</p> + +<p>Two major issues in web performance are understanding issues having to do with latency and issues having to do with the fact that for the most part, browsers are single threaded.</p> + +<p>Latency is our main threat to overcome to ensure a fast load. To be fast to load, the developers’ goals include sending requested information as fast as possible, or at least seem super fast. Network latency is the time it takes to transmit bytes over-the-air to computers. Web performance is what we have to do to make the page load happen as quickly as possible.</p> + +<p>For the most part, browsers are considered single threaded. For smooth interactions, the developer's goal is to ensure performant site interactions, from smooth scrolling to being responsive to touch. Render time is key, with ensuring the main thread can complete all the work we throw at it and still always be available to handle user interactions. Web performance can be improved by understanding the single-threaded nature of the browser and minimizing the main thread's responsibilities, where possible and appropriate, to ensure rendering is smooth and responses to interactions are immediate.</p> + +<h2 id="Navigation">Navigation</h2> + +<p><em>Navigation</em> is the first step in loading a web page. It occurs whenever a user requests a page by entering a URL into the address bar, clicking a link, submitting a form, as well as other actions.</p> + +<p>One of the goals of web performance is to minimize the amount of time a navigation takes to complete. In ideal conditions, this usually doesn't take too long, but latency and bandwidth are foes which can cause delays.</p> + +<h3 id="DNS_Lookup">DNS Lookup</h3> + +<p>The first step of navigating to a web page is finding where the assets for that page are located. If you navigate to <code>https://example.com</code>, the HTML page is located on the server with IP address of <code>93.184.216.34</code>. If you’ve never visited this site, a DNS lookup must happen.</p> + +<p>Your browser requests a DNS lookup, which is eventually fielded by a name server, which in turn responds with an IP address. After this initial request, the IP will likely be cached for a time, which speeds up subsequent requests by retrieving the IP address from the cache instead of contacting a name server again.</p> + +<p>DNS lookups usually only need to be done once per hostname for a page load. However, DNS lookups must be done for each unique hostname the requested page references. If your fonts, images, scripts, ads, and metrics all have different hostnames, a DNS lookup will have to be made for each one.</p> + +<p><img alt="Mobile requests go first to the cell tower, then to a central phone company computer before being sent to the internet" src="https://mdn.mozillademos.org/files/16743/latency.jpg" style="height: 281px; width: 792px;"></p> + +<p>This can be problematic for performance, particularly on mobile networks. When a user is on a mobile network, each DNS lookup has to go from the phone to the cell tower to reach an authoritative DNS server. The distance between a phone, a cell tower, and the name server can add significant latency.</p> + +<h3 id="TCP_Handshake">TCP Handshake</h3> + +<p>Once the IP address is known, the browser sets up a connection to the server via a {{glossary('TCP handshake','TCP three-way handshake')}}. This mechanism is designed so that two entities attempting to communicate—in this case the browser and web server—can negotiate the parameters of the network TCP socket connection before transmitting data, often over {{glossary('HTTPS')}}.</p> + +<p>TCP's three way handshaking technique is often referred to as "SYN-SYN-ACK"—or more accurately SYN, SYN-ACK, ACK—because there are three messages transmitted by TCP to negotiate and start a TCP session between two computers. Yes, this means three more messages back and forth between each server, and the request has yet to be made.</p> + +<h3 id="TLS_Negotiation">TLS Negotiation</h3> + +<p>For secure connections established over HTTPS, another "handshake" is required. This handshake, or rather the {{glossary('TLS')}} negotiation, determines which cipher will be used to encrypt the communication, verifies the server, and establishes that a secure connection is in place before beginning the actual transfer of data. This requires three more round trips to the server before the request for content is actually sent.</p> + +<p><img alt="The DNS lookup, the TCP handshake, and 5 steps of the TLS handshake including clienthello, serverhello and certificate, clientkey and finished for both server and client." src="https://mdn.mozillademos.org/files/16746/ssl.jpg" style="height: 412px; width: 729px;"></p> + +<p>While making the connection secure adds time to the page load, a secure connection is worth the latency expense, as the data transmitted between the browser and the web server cannot be decrypted by a third party.</p> + +<p>After the 8 round trips, the browser is finally able to make the request.</p> + +<h2 id="Response">Response</h2> + +<p>Once we have an established connection to a web server, the browser sends an initial <a href="/en-US/docs/Web/HTTP/Methods">HTTP <code>GET</code> request</a> on behalf of the user, which for websites is most often an HTML file. Once the server receives the request, it will reply with relevant response headers and the contents of the HTML.</p> + +<pre class="brush: html notranslate"><!doctype HTML> +<html> + <head> + <meta charset="UTF-8"/> + <title>My simple page</title> + <link rel="stylesheet" src="styles.css"/> + <script src="myscript.js"></script> +</head> +<body> + <h1 class="heading">My Page</h1> + <p>A paragraph with a <a href="https://example.com/about">link</a></p> + <div> + <img src="myimage.jpg" alt="image description"/> + </div> + <script src="anotherscript.js"></script> +</body> +</html></pre> + +<p>This response for this initial request contains the first byte of data received. {{glossary('Time to First Byte')}} (TTFB) is the time between when the user made the request—say by clicking on a link—and the receipt of this first packet of HTML. The first chunk of content is usually 14kb of data.</p> + +<p>In our example above, the request is definitely less than 14Kb, but the linked resources aren't requested until the browser encounters the links during parsing, described below.</p> + +<h3 id="TCP_Slow_Start_14kb_rule">TCP Slow Start / 14kb rule</h3> + +<p>The first response packet will be 14Kb. This is part of {{glossary('TCP slow start')}}, an algorithm which balances the speed of a network connection. Slow start gradually increases the amount of data transmitted until the network's maximum bandwidth can be determined.</p> + +<p>In {{glossary('TCP slow start')}}, after receipt of the initial packet, the server doubles the size of the next packet to around 28Kb. Subsequent packets increase in size until a predetermined threshold is reached, or congestion is experienced.</p> + +<p><img alt="TCP slow start" src="https://mdn.mozillademos.org/files/16754/congestioncontrol.jpg" style="height: 412px; width: 729px;"></p> + +<p>If you’ve ever heard of the 14Kb rule for initial page load, TCP slow start is the reason why the initial response is 14Kb, and why web performance optimization calls for focusing optimizations with this initial 14Kb response in mind. TCP slow start gradually builds up transmission speeds appropriate for the network's capabilities to avoid congestion.</p> + +<h3 id="Congestion_control">Congestion control</h3> + +<p><span style="font-weight: 400;">As the server sends data in TCP packets, the user's client confirms delivery by returning acknowledgements, or ACKs. The connection has a limited capacity depending on hardware and network conditions. If the server sends too many packets too quickly, they will be dropped. Meaning, there will be no acknowledgement. The server registers this as missing ACKs. Congestion control algorithms use this flow of sent packets and ACKs to determine a send rate.</span></p> + +<h2 id="Parsing">Parsing</h2> + +<p>Once the browser receives the first chunk of data, it can begin parsing the information received. {{glossary('speculative parsing', 'Parsing')}} is the step the browser takes to turn the data it receives over the network into the {{glossary('DOM')}} and {{glossary('CSSOM')}}, which is used by the renderer to paint a page to the screen.</p> + +<p>The DOM is the internal representation of the markup for the browser. The DOM is also exposed, and can be manipulated through various APIs in JavaScript.</p> + +<p>Even if the request page's HTML is larger than the initial 14KB packet, the browser will begin parsing and attempting to render an experience based on the data it has. This is why it's important for web performance optimization to include everything the browser needs to start rendering a page, or at least a template of the page - the CSS and HTML needed for the first render -- in the first 14 kilobytes. But before anything is rendered to the screen, the HTML, CSS, and JavaScript have to be parsed.</p> + +<h3 id="Building_the_DOM_tree">Building the DOM tree</h3> + +<p>We describe five steps in the <a href="/en-US/docs/Web/Performance/Critical_rendering_path">critical rendering path</a>.</p> + +<p>The first step is processing the HTML markup and building the DOM tree. HTML parsing involves <a href="/en-US/docs/Web/API/DOMTokenList">tokenization</a> and tree construction. HTML tokens include start and end tags, as well as attribute names and values. If the document is well-formed, parsing it is straightforward and faster. The parser parses tokenized input into the document, building up the document tree.</p> + +<p>The DOM tree describes the content of the document. The <code><a href="/en-US/docs/Web/HTML/Element/html"><html></a></code> element is the first tag and root node of the document tree. The tree reflects the relationships and hierarchies between different tags. Tags nested within other tags are child nodes. The greater the number of DOM nodes, the longer it takes to construct the DOM tree.</p> + +<p><img alt="The DOM tree for our sample code, showing all the nodes, including text nodes." src="https://mdn.mozillademos.org/files/16759/DOM.gif" style="height: 689px; width: 754px;"></p> + +<p>When the parser finds non-blocking resources, such as an image, the browser will request those resources and continue parsing. Parsing can continue when a CSS file is encountered, but <code><script></code> tags—particularly those without an <code><a href="/en-US/docs/Web/JavaScript/Reference/Statements/async_function">async</a></code> or <code>defer</code> attribute—block rendering, and pause the parsing of HTML. Though the browser's preload scanner hastens this process, excessive scripts can still be a significant bottleneck.</p> + +<h3 id="Preload_scanner">Preload scanner</h3> + +<p>While the browser builds the DOM tree, this process occupies the main thread. As this happens, the <em>preload scanner</em> will parse through the content available and request high priority resources like CSS, JavaScript, and web fonts. Thanks to the preload scanner, we don't have to wait until the parser finds a reference to an external resource to request it. It will retrieve resources in the background so that by the time the main HTML parser reaches requested assets, they may possibly already be in flight, or have been downloaded. The optimizations the preload scanner provides reduce blockages.</p> + +<pre class="brush:html notranslate"><link rel="stylesheet" src="styles.css"/> +<script src="myscript.js" <strong>async</strong>></script> +<img src="myimage.jpg" alt="image description"/> +<script src="anotherscript.js" <strong>async</strong>></script> +</pre> + +<p>In this example, while the main thread is parsing the HTML and CSS, the preload scanner will find the scripts and image, and start downloading them as well. To ensure the script doesn't block the process, add the <code>async</code> attribute, or the <code>defer</code> attribute if JavaScript parsing and execution order is not important.</p> + +<p>Waiting to obtain CSS doesn't block HTML parsing or downloading, but it does block JavaScript, because JavaScript is often used to query CSS properties’ impact on elements.</p> + +<h3 id="Building_the_CSSOM">Building the CSSOM</h3> + +<p>The second step in the critical rendering path is processing CSS and building the CSSOM tree. The CSS object model is similar to the DOM. <span style="color: #212121; display: inline !important; float: none; font-family: Roboto,sans-serif; font-size: 16px; font-style: normal; font-weight: 400; letter-spacing: normal; text-align: left; text-decoration-style: initial; text-indent: 0px; text-transform: none; white-space: normal;">The DOM and CSSOM are both trees. They are independent data structures</span>. The browser converts the CSS rules into a map of styles it can understand and work with. The browser goes through each rule set in the CSS, creating a tree of nodes with parent, child, and sibling relationships based on the CSS selectors.</p> + +<p>As with HTML, the browser needs to convert the received CSS rules into something it can work with. Hence, it repeats the HTML-to-object process, but for the CSS.</p> + +<p>The CSSOM tree includes styles from the user agent style sheet. The browser begins with the most general rule applicable to a node and recursively refines the computed styles by applying more specific rules. In other words, it cascades the property values.</p> + +<p>Building the CSSOM is very, very fast and is not displayed in a unique color in current developer tools. Rather, the "Recalculate Style" in developer tools shows the total time it takes to parse CSS, construct the CSSOM tree, and recursively calculate computed styles. In terms of web performance optimization, there are lower hanging fruit, as the total time to create the CSSOM is generally less than the time it takes for one DNS lookup.</p> + +<h3 id="Other_Processes">Other Processes</h3> + +<h4 id="JavaScript_Compilation">JavaScript Compilation</h4> + +<p>While the CSS is being parsed and the CSSOM created, other assets, including JavaScript files, are downloading (thanks to the preload scanner). JavaScript is interpreted, compiled, parsed and executed. The scripts are parsed into abstract syntax trees. Some browser engines take the {{glossary('Abstract Syntax Tree')}} and pass it into an interpreter, outputting bytecode which is executed on the main thread. This is known as JavaScript compilation.</p> + +<h4 id="Building_the_Accessibility_Tree">Building the Accessibility Tree</h4> + +<p>The browser also builds an <a href="/en-US/docs/Learn/Accessibility">accessibility</a> tree that assistive devices use to parse and interpret content. The accessibility object model (AOM) is like a semantic version of the DOM. The browser updates the accessibility tree when the DOM is updated. The accessibility tree is not modifiable by assistive technologies themselves.</p> + +<p>Until the AOM is built, the content is not accessible to <a href="/en-US/docs/Web/Accessibility/ARIA/ARIA_Screen_Reader_Implementors_Guide">screen readers</a>.</p> + +<h2 id="Render">Render</h2> + +<p>Rendering steps include style, layout, paint and, in some cases, compositing. The CSSOM and DOM trees created in the parsing step are combined into a render tree which is then used to compute the layout of every visible element, which is then painted to the screen. In some cases, content can be promoted to their own layers and composited, improving performance by painting portions of the screen on the GPU instead of the CPU, freeing up the main thread.</p> + +<h3 id="Style">Style</h3> + +<p>The third step in the critical rendering path is combining the DOM and CSSOM into a render tree.The computed style tree, or render tree, construction starts with the root of the DOM tree, traversing each visible node.</p> + +<p>Tags that aren't going to be displayed, like the <code><a href="/en-US/docs/Web/HTML/Element/head"><head></a></code> and its children and any nodes with <code>display: none</code>, such as the <code>script { display: none; }</code> you will find in user agent stylesheets, are not included in the render tree as they will not appear in the rendered output. Nodes with <code>visibility: hidden</code> applied are included in the render tree, as they do take up space. As we have not given any directives to override the user agent default, the <code>script</code> node in our code example above will not be included in the render tree.</p> + +<p>Each visible node has its CSSOM rules applied to it. The render tree holds all the visible nodes with content and computed styles -- matching up all the relevant styles to every visible node in the DOM tree, and determining, based on the <a href="/en-US/docs/Web/CSS/Cascade">CSS cascade</a>, what the computed styles are for each node.</p> + +<h3 id="Layout">Layout</h3> + +<p>The fourth step in the critical rending path is running layout on the render tree to compute the geometry of each node. <em>Layout</em> is the process by which the width, height, and location of all the nodes in the render tree are determined, plus the determination of the size and position of each object on the page. <em>Reflow</em> is any subsequent size and position determination of any part of the page or the entire document.</p> + +<p>Once the render tree is built, layout commences. The render tree identified which nodes are displayed (even if invisible) along with their computed styles, but not the dimensions or location of each node. To determine the exact size and location of each object, the browser starts at the root of the render tree and traverses it.</p> + +<p>On the web page, most everything is a box. Different devices and different desktop preferences mean an unlimited number of differing viewport sizes. In this phase, taking the viewport size into consideration, the browser determines what the dimensions of all the different boxes are going to be on the screen. Taking the size of the viewport as its base, layout generally starts with the body, laying out the dimensions of all the body’s descendants, with each element's box model properties, providing placeholder space for replaced elements it doesn’t know the dimensions of, such as our image.</p> + +<p>The first time the size and position of nodes are determined is called <em>layout</em>. Subsequent recalculations of node size and locations are called <em>reflows</em>. In our example, suppose the initial layout occurs before the image is returned. Since we didn't declare the size of our image, there will be a reflow once the image size is known.</p> + +<h3 id="Paint">Paint</h3> + +<p>The last step in the critical rendering path is painting the individual nodes to the screen, the first occurence of which is called the <a href="/en-US/docs/Glossary/first_meaningful_paint">first meaningful paint</a>. In the painting or rasterization phase, the browser converts each box calculated in the layout phase to actual pixels on the screen. Painting involves drawing every visual part of an element to the screen, including text, colors, borders, shadows, and replaced elements like buttons and images. The browser needs to do this super quickly.</p> + +<p>To ensure smooth scrolling and animation, everything occupying the main thread, including calculating styles, along with reflow and paint, must take the browser less than 16.67ms to accomplish. At 2048 X 1536, the iPad has over 3,145,000 pixels to be painted to the screen. That is a lot of pixels that have to be painted very quickly. To ensure repainting can be done even faster than the initial paint, the drawing to the screen is generally broken down into several layers. If this occurs, then compositing is necessary.</p> + +<p>Painting can break the elements in the layout tree into layers. Promoting content into layers on the GPU (instead of the main thread on the CPU) improves paint and repaint performance. There are specific properties and elements that instantiate a layer, including <code><a href="/en-US/docs/Web/HTML/Element/video"><video></a></code> and <code><a href="/en-US/docs/Web/HTML/Element/canvas"><canvas></a></code>, and any element which has the CSS properties of <a href="/en-US/docs/Web/CSS/opacity"><code>opacity</code></a>, a 3D <code><a href="/en-US/docs/Web/CSS/transform">transform</a></code>, <code><a href="/en-US/docs/Web/CSS/will-change">will-change</a></code>, and a few others. These nodes will be painted onto their own layer, along with their descendants, unless a descendant necessitates its own layer for one (or more) of the above reasons.</p> + +<p>Layers do improve performance, but are expensive when it comes to memory management, so should not be overused as part of web performance optimization strategies.</p> + +<h3 id="Compositing">Compositing</h3> + +<p>When sections of the document are drawn in different layers, overlapping each other, compositing is necessary to ensure they are drawn to the screen in the right order and the content is rendered correctly.</p> + +<p>As the page continues to load assets, reflows can happen (recall our example image that arrived late). A reflow sparks a repaint and a re-composite. Had we defined the size of our image, no reflow would have been necessary, and only the layer that needed to be repainted would be repainted, and composited if necessary. But we didn't include the image size! When the image is obtained from the server, the rendering process goes back to the layout steps and restarts from there.</p> + +<h2 id="Interactivity">Interactivity</h2> + +<p>Once the main thread is done painting the page, you would think we would be "all set." That isn't necessarily the case. If the load includes JavaScript, that was correctly deferred, and only executed after the <code><a href="/en-US/docs/Web/API/GlobalEventHandlers/onload">onload</a></code> event fires, the main thread might be busy, and not available for scrolling, touch, and other interactions.</p> + +<p>{{glossary('Time to Interactive')}} (TTI) is the measurement of how long it took from that first request which led to the DNS lookup and SSL connection to when the page is interactive -- interactive being the point in time after the {{glossary('First Contentful Paint')}} when the page responds to user interactions within 50ms. If the main thread is occupied parsing, compiling, and executing JavaScript, it is not available and therefore not able to responsd to user interactions in a timely (less than 50ms) fashion.</p> + +<p>In our example, maybe the image loaded quickly, but perhaps the <code>anotherscript.js</code> file was 2MB and our user's network connection was slow. In this case the user would see the page super quickly, but wouldn't be able to scroll without jank until the script was downloaded, parsed and executed. That is not a good user experience. Avoid occupying the main thread, as demonstrated in this WebPageTest example:</p> + +<p><img alt="The main thread is occupied by the downloading, parsing and execution of a javascript file - over a fast connection" src="https://mdn.mozillademos.org/files/16760/visa_network.png" style="height: 699px; width: 1200px;"></p> + +<p>In this example, the DOM content load process took over 1.5 seconds, and the main thread was fully occupied that entire time, unresponsive to click events or screen taps.</p> + +<h2 id="See_Also">See Also</h2> + +<ul> + <li><a href="/en-US/docs/Web/Performance">Web Performance</a></li> +</ul> diff --git a/files/es/web/performance/index.html b/files/es/web/performance/index.html new file mode 100644 index 0000000000..9b27ba854c --- /dev/null +++ b/files/es/web/performance/index.html @@ -0,0 +1,242 @@ +--- +title: Rendimiento Web +slug: Web/Performance +tags: + - Mejores Practicas + - Pagina de Inicio + - Rendimiento + - Rendimiento Web +translation_of: Web/Performance +--- +<div>{{draft}}</div> + +<p><span class="seoSummary">El rendimiento web es la medición objetiva y la experiencia percibida por el usuario del tiempo de carga y el tiempo de ejecución; es el tiempo que tarda un sitio en cargarse, ser interactivo y responsivo, y que tan fluido es el contenido durante las interacciones del usuario: ¿el desplazamiento es suave? ¿Se puede hacer clic en los botones? ¿Las ventanas emergentes se abren rápidamente y se animan fluidamente al hacerlo? El rendimiento web incluye mediciones objetivas como el tiempo de carga, cuadros por segundo y tiempo para interactuar y subjetivas de cuánto tiempo se sintió que tardó en cargarse el contenido.</span></p> + +<p><span class="seoSummary">Cuanto más tarde un sitio en responder, más usuarios abandonarán el sitio. Es importante minimizar los tiempos de carga y respuesta, y agregar funciones adicionales para ocultar la latencia al hacer que la experiencia sea lo más accesible e interactiva posible, tan pronto como sea posible, mientras se carga de forma asíncrona en las partes que más tarda la experiencia.</span></p> + +<p><span class="seoSummary">Existen herramientas, API y mejores prácticas que nos ayudan a medir y mejorar el rendimiento web. Los cubrimos en esta sección.</span></p> + +<div class="cleared topicpage-table"> +<div class="section"> +<h2 id="Tutoriales_claves">Tutoriales claves</h2> + +<p>El <a href="/en-US/docs/Learn/Performance">Área de aprendizaje de Rendimiento</a> Web de MDN contiene tutoriales modernos y actualizados que cubren aspectos esenciales del rendimiento:<br> + </p> + +<p><a href="/en-US/docs/Learn/Performance/What_is_web_performance">¿Qué es el rendimiento web?</a></p> + +<p>Este artículo inicia el módulo con un buen vistazo a lo que realmente es el rendimiento: esto incluye las herramientas, métricas, API, redes y grupos de personas que debemos tener en cuenta al pensar en el rendimiento y cómo podemos hacer que el rendimiento sea parte de nuestro flujo de trabajo de desarrollo web.</p> + +<dl> + <dt><a href="/en-US/docs/Web/Performance/Critical_rendering_path">Ruta crítica de renderización</a></dt> + <dd>Algunos atributos y el orden en los origenes del código pueden afectar el rendimiento o su sitio web. Al minimizar el número de nodos del DOM, asegurándose de utilizar el mejor orden y los atributos para el contenido incluido, como estilos, código, elementos multimedia y código de terceros, puede mejorar drásticamente la experiencia del usuario. Este artículo analiza en detalle cómo el HTML y la ruta crítica de renderización pueden usarse para garantizar el máximo rendimiento.</dd> + <dt><a href="/en-US/docs/Learn/Performance/JavaScript">Mejores prácticas de rendimiento de Javascript</a></dt> + <dd>JavaScript, cuando se usa correctamente, puede permitir experiencias web interactivas e inmersivas ... o puede dañar significativamente el tiempo de descarga, el tiempo de reproducción, el rendimiento de la aplicación, la duración de la batería y la experiencia del usuario. Este artículo describe algunas de las mejores prácticas de JavaScript que pueden garantizar que, incluso el contenido más complejo, tenga el mejor rendimiento posible.<br> + </dd> + <dt><a href="/en-US/docs/Learn/Performance/Multimedia">Multimedia: Images and Video</a></dt> + <dd>Con frecuencia, la optimización de elementos multimedia es la forma más usada de hacer rendimiento web. Es posible servir diferentes archivos multimedia según el tipo de navegador, el tamaño y la densidad de píxeles de cada usuario. Consejos adicionales, como eliminar el sonido en imágenes de fondo, pueden mejorar aún más el rendimiento. En este artículo, analizamos el impacto que el video, el audio y el contenido de imagen tienen en el rendimiento y los métodos para garantizar que su impacto sea el mínimo posible.</dd> + <dt><a href="/en-US/docs/Learn/Performance/CSS_performance">Características de rendimiento CSS </a></dt> + <dd>CSS puede tener un enfoque de optimización menos importante para mejorar el rendimiento, pero hay algunas características de CSS que afectan el rendimiento más que otras. En este artículo, analizamos algunas propiedades de CSS que afectan el rendimiento y sugerimos formas de manejar los estilos para garantizar que el rendimiento no se vea afectado negativamente.</dd> + <dt><a href="/en-US/docs/Learn/Performance/perceived_performance">¿Como los usuarios perciben el rendimiento?</a></dt> + <dd> + <p>Más importante que la rapidez de su sitio web en milisegundos, es la rapidez con la que los usuarios perciben su sitio. El tiempo de carga, el tiempo en ocio de la página, la capacidad de respuesta a la interacción del usuario y lo fluido de los desplazamientos y otras animaciones afectan estas percepciones. En este artículo, analizamos las diversas métricas de carga, animación y métricas de capacidad de respuesta, junto con las mejores prácticas para mejorar la percepción del usuario, y de los tiempos reales.</p> + </dd> + <dt><a href="/en-US/docs/Learn/Performance/web_performance_basics">Conceptos básicos de rendimiento web</a></dt> + <dd>Además de los componentes HTML, CSS, JavaScript y archivos multimedia, hay características que pueden hacer que las aplicaciones sean más lentas y características que pueden hacer que las aplicaciones sean subjetivamente y objetivamente más rápidas. Existen muchas API, herramientas de desarrollo, mejores prácticas y malas prácticas relacionadas con el rendimiento web. Aquí presentaremos muchas de estas funciones al nivel básico y proporcionaremos enlaces a temas más profundos para mejorar el rendimiento en cada tema.</dd> + <dt> + <p><a href="/en-US/docs/Learn/Performance/Mobile">Rendimiento movil</a></p> + </dt> + <dd> + <p>Dado que el acceso a la web en dispositivos móviles es tan popular y que todas las plataformas móviles tienen navegadores web completos, pero es posible que el ancho de banda, la CPU y la vida útil de la batería sean limitados, es importante considerar el rendimiento de su contenido web en estas plataformas. Este artículo analiza las consideraciones de rendimiento específicas para dispositivos móviles.</p> + </dd> + <dt>Llenando la página</dt> + <dd>El cliente realiza una solicitud HTTP y, con suerte, unos segundos después, aparece el sitio. Mostrar el contenido implica ejecutar JavaScript, posiblemente modificando el DOM, calcular estilos, calcular la disposición del diseño y, finalmente, representar el contenido, lo que implica pintar y componer, y puede involucrar la aceleración de la GPU en un hilo de ejecución separado.<br> + .</dd> + <dt>Cuellos de botella en rendimiento </dt> + <dd> </dd> + <dt><a href="/en-US/docs/Web/Performance/time_to_interactive">Tiempo para interactuar</a></dt> + <dd> </dd> + <dt><a href="/en-US/docs/Learn/Performance/Latency">Entendiendo la latencia</a></dt> + <dd> + <p>La latencia es la cantidad de tiempo que se tarda entre realizar una solicitud de un recurso y recibir el primer byte del recurso solicitado. Este artículo explica qué es la latencia, cómo afecta el rendimiento y cómo medir y mejorar la latencia.</p> + </dd> + <dt>Entendiendo ancho de banda </dt> + <dd> + <div> + <div class="public-DraftStyleDefault-block public-DraftStyleDefault-ltr"><span><span>El ancho de banda es la cantidad de datos (medidos en Mbps o Kbps) que uno puede enviar por segundo. Este artículo explica la función del ancho de banda en las aplicaciones de Internet ricas en elementos multimedia, cómo puede medirlo y cómo puede optimizar las aplicaciones para aprovechar al máximo el ancho de banda disponible.</span></span></div> + </div> + </dd> + <dt><a href="/en-US/docs/Learn/Performance/HTTP2">HTTP/2 y tu</a></dt> + <dd> + <p>La capa de transporte, es decir, HTTP, es absolutamente esencial para el funcionamiento de la web, y solo recientemente se ha visto una actualización importante en la forma de HTTP/2. Viendolo de otra forma HTTP/2 proporciona muchas mejoras de rendimiento y ventajas sobre su predecesor, pero también cambia el panorama. En este artículo, aprenderá lo que HTTP/2 hace por usted, y cómo ajustar su aplicación para que vaya más allá.</p> + </dd> + <dt>El papel de TLS en el rendimiento</dt> + <dd> + <p>TLS o HTTPS, como solemos llamarlo, es crucial para crear experiencias de usuario seguras. Si bien el hardware ha reducido los impactos negativos que TLS ha tenido en el rendimiento del servidor, todavía representa una porción sustancial del tiempo que pasamos esperando que los navegadores se conecten a los servidores. Este artículo explica el proceso de reconocimiento de TLS y ofrece algunos consejos para reducir este tiempo, como el grapado OCSP, los encabezados de precarga de HSTS y el posible papel de las sugerencias de recursos en el enmascaramiento de la latencia TLS para terceros.<br> + </p> + </dd> + <dt>Leyendo gráficos de rendimientos </dt> + <dd>Las herramientas del desarrollador proporcionan información sobre el rendimiento, la memoria y las solicitudes de red. Saber cómo leer los cuadros de cascada, los árboles de llamadas, los trazos, los gráficos de llamas y las asignaciones de memoria en las herramientas de desarrollo de su navegador lo ayudará a comprender los cuadros de cascada y de llama en otras herramientas de rendimiento.</dd> + <dt>Analizando paquetes de JavaScript</dt> + <dd><span><span>Sin duda, JavaScript es una gran parte del desarrollo web moderno. Si bien siempre debemos esforzarnos por reducir la cantidad de JavaScript que se utiliza en nuestas aplicaciones, puede ser difícil saber dónde comenzar. En esta guía, le mostraremos cómo analizar los paquetes de scripts de su aplicación, para que sepa qué está utilizando y cómo detectar si su aplicación contiene scripts duplicados entre paquetes.</span></span></dd> + <dt><br> + </dt> + <dt><a href="/en-US/docs/Web/Performance/Lazy_loading">Carga diferida </a></dt> + <dd>No siempre es necesario cargar todos los activos de aplicaciones web en la carga de la página inicial. La carga diferida es diferir la carga de elementos en una página, como scripts, imágenes, etc., para un momento posterior, cuando esos elementos son realmente necesarios.</dd> + <dd> </dd> +</dl> + +<dl> + <dt>Carga diferida de JavaScript con import()</dt> + <dd>El término "carga diferida" a menudo se refiere a técnicas de aplazamiento de carga para elementos que no se muestran en la vista inicial de la página solo cuando el usuario se desplaza hacia esos elementos en la página. Ahora hay características nativas para cargar JavaScript! En esta guía, hablaremos sobre el compando import() de carga dinamica, una nueva función del navegador, que carga un módulo de JavaScript a pedido.</dd> + <dt><a href="/en-US/docs/Web/Performance/Controlling_resource_delivery_with_resource_hints">Controlar la entrega de recursos con sugerencias de recursos</a></dt> + <dd>Los navegadores a menudo saben mejor que nosotros cuando se trata de la priorización y la entrega de recursos, pero están lejos de ser clarividentes. Las características nativas del navegador nos permiten sugerirle al navegador cuándo debe conectarse a otro servidor, o precargar un recurso antes de que el navegador sepa que lo necesita. Cuando se usa juiciosamente, esto puede hacer que la experiencia rápida parezca aún más rápida. En este artículo, cubrimos las características nativas del navegador como rel = preconnect, rel = dns-prefetch, rel = prefetch y rel = precarga, y cómo usarlas para su ventaja.</dd> +</dl> +</div> + +<div class="section"> +<h2 class="Other_documentation" id="Other_documentation" name="Other_documentation">Documentacion adicional</h2> + +<dl> + <dt><a href="/en-US/docs/Web/Performance/business_case_for_performance">Caso de negocio para rendimiento web</a></dt> + <dd> + <p>Usted sabe que el rendimiento web es importante, pero ¿cómo convencer a los clientes y a la administrativos para que inviertan en el rendimiento y lo conviertan en una prioridad? En este artículo, discutiremos la creación de un caso de negocio claro para convencer a los tomadores de decisiones para que hagan la inversión.</p> + </dd> + <dt><a href="/en-US/docs/Web/Performance/Performance_budget">Presupuestos de rendimiento</a></dt> + <dd>Las necesidades de mercadotecnia, diseño y ventas, y la experiencia del desarrollador, grandes anuncios, scripts de terceros y otras características que pueden ralentizar el rendimiento web. Para ayudar a establecer prioridades, es útil establecer un presupuesto de desempeño: un conjunto de restricciones que no deben excederse durante la fase de desarrollo. En este artículo, analizaremos la creación y el apego a un presupuesto de rendimiento.</dd> + <dt><a href="/en-US/docs/Web/Performance/Mobile_performance_checklist">Lista de pendientes de rendimiento móvil </a></dt> + <dd>Una lista de pendientes concisa de las consideraciones de rendimiento que afectan a los usuarios de redes móviles en dispositivos portátiles que funcionan con baterías.</dd> + <dt><a href="/en-US/docs/Web/Apps/Fundamentals/Performance/Optimizing_startup_performance">Optimización del rendimiento de inicio </a></dt> + <dd>¿Cuánto tiempo demora su aplicación en iniciarse? ¿Bloquea el navegador mientras se carga? Tómese el tiempo para asegurarse de que su aplicación se inicie bien. Este artículo ofrece consejos y sugerencias para ayudarle a alcanzar ese objetivo.</dd> + <dt><a href="/en-US/docs/Tools/Performance">Funciones de rendimiento en las herramientas de desarrollo</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>.<br> + Esta sección proporciona información sobre cómo utilizar y comprender las funciones de rendimiento en sus herramientas de desarrollador, incluidos <a href="/en-US/docs/Tools/Performance/Waterfall">gráficos de cascada</a>, <a href="/en-US/docs/Tools/Performance/Call_Tree">árbol de llamadas</a> y <a href="/en-US/docs/Tools/Performance/Flame_Chart">gráficos de llamas</a></dd> +</dl> + +<dl> + <dt> </dt> + <dt><a href="/en-US/docs/Learn/Performance/Latency">Entendiendo la latencia</a></dt> + <dd> + <p>La latencia es la cantidad de tiempo que se tarda entre realizar una solicitud de un recurso y recibir el primer byte del recurso solicitado. Este artículo explica qué es la latencia, cómo afecta el rendimiento y cómo medir y mejorar la latencia.</p> + </dd> + <dt><a href="/en-US/docs/Web/Performance/Checklist">Lista de control de rendimiento web</a></dt> + <dd>Una lista de verificación del rendimiento de las funciones que se deben tener en cuenta al desarrollar aplicaciones con enlaces a tutoriales sobre cómo implementar cada una de ellas, incluye service workers, diagnóstico de problemas de rendimiento, mejores prácticas de carga de fuentes, sugerencias para los clientes, creación de animaciones optimizadas, etc.</dd> + <dt> </dt> +</dl> + +<h3 id="Rendimiento_de_aplicaciones">Rendimiento de aplicaciones</h3> + +<dl> + <dt><a href="/en-US/Apps/Developing/Performance/Performance_fundamentals">Fundamentos de rendimiento</a></dt> + <dd>Una visión general del rendimiento de las aplicaciones web, qué es, cómo el navegador ayuda a mejorarlo, y qué herramientas y procesos puede utilizar para probar y mejorarlo aún más.</dd> + <dt><a href="/en-US/Apps/Developing/Performance/Optimizing_startup_performance">Optimizando el rendimiento de inicio</a></dt> + <dd>Consejos y sugerencias para ayudarlo a mejorar el rendimiento de inicio, tanto al escribir una nueva aplicación como al migrar una aplicación de otra plataforma a la Web.</dd> + <dt><a href="/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler">Profiling con el profiler integrado</a> </dt> + <dd>Aprenda como rastrear el performance de las aplicaciones con el profiler integrado de Firefox.</dd> + <dt><a href="/en-US/Apps/Build/Performance/CSS_JavaScript_animation_performance">Rendimiento en animaciones con CSS y con JavaScript </a></dt> + <dd>Las animaciones son críticas para una experiencia de usuario placentera. Este artículo analiza las diferencias de rendimiento entre las animaciones basadas en CSS y JavaScript. </dd> +</dl> + +<p><span class="alllinks"><a href="/en-US/docs/tag/Performance">Ver todos los articulos acerca de rendimiento...</a></span></p> +</div> +</div> + +<p>{{LandingPageListSubpages}}</p> + +<h2 id="Ver_También">Ver También</h2> + +<p>HTML</p> + +<ul> + <li><a href="/en-US/docs/Web/HTML/Element/picture">El elemento <code><picture></code> </a></li> + <li><a href="/en-US/docs/Web/HTML/Element/video">El elemento <code><video></code></a></li> + <li><a href="/en-US/docs/Web/HTML/Element/source">El elemento <code><source></code></a></li> + <li><a href="/en-US/docs/Web/HTML/Element/img#Attributes">El atributo <code><img> srcset</code> </a> + <ul> + <li><a href="/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images">Imagenes responsivas</a></li> + </ul> + </li> + <li><a href="/en-US/docs/Web/HTML/Preloading_content">Precargando contenido con <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>Midiendo disposición del diseño</li> + <li>Mejores practicas en carga de fuentes</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">Recolector de basura </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> diff --git a/files/es/web/performance/mejorando_rendimienot_inicial/index.html b/files/es/web/performance/mejorando_rendimienot_inicial/index.html new file mode 100644 index 0000000000..ed8bc6771d --- /dev/null +++ b/files/es/web/performance/mejorando_rendimienot_inicial/index.html @@ -0,0 +1,95 @@ +--- +title: Mejorando el Rendimiento Inicial +slug: Web/Performance/mejorando_rendimienot_inicial +tags: + - Apps + - Performance + - Rendimiento +translation_of: Web/Performance/Optimizing_startup_performance +--- +<div class="summary"> +<p>Un aspecto que a menudo se pasa por alto en el desarrollo de software de aplicaciones, incluso entre aquellos enfocados en la optimización del rendimiento, es el rendimiento inicial. ¿Cuánto tiempo demora su aplicación en iniciarse? ¿Parece que se bloquea el dispositivo o el navegador del usuario no responde mientras se carga la aplicación? Eso hace que los usuarios se preocupen de que su aplicación haya fallado, o de que algo anda mal. Siempre es una buena idea invertir tiempo para asegurarse de que la aplicación se inicie de manera correcta. Este artículo ofrece consejos y sugerencias para ayudar a lograr ese objetivo, tanto al escribir una nueva aplicación como al migrar una aplicación de otra plataforma a la Web.</p> +</div> + +<h2 id="Empezando_Bien">Empezando Bien</h2> + +<p>Independientemente de la plataforma, siempre es una buena idea comenzar lo <strong>más rápido </strong>posible. Ya que es un problema universal, no nos vamos a enfocar demasiado en esto. En su lugar, vamos a ver un problema más importante al crear aplicaciones web: comenzar de la manera más <strong>asíncrona </strong>posible. Eso significa no ejecutar todo el código inicial en un mismo controlador de eventos en el hilo principal de la aplicación.</p> + +<p>En su lugar, es preferible que el código de la aplicación cree un <a href="es/docs/Web/Guide/Performance/Usando_web_workers" title="/en-US/docs/DOM/Using_web_workers">Web worker</a> que haga todo lo posible en un hilo de fondo (por ejemplo, para obtener y procesar datos). Luego, todo lo que debe ejecutarse en el hilo principal (como responder a los eventos del usuario o desplegar la interfaz gráfica) debe dividirse en tareas pequeñas para que el ciclo de eventos continúe mientras la aplicación inicia. Esto evitará que la aplicación, el navegador y / o el dispositivo parezcan haber fallado.</p> + +<p>¿Por qué es importante ser asíncrono? <span title="">Aparte de las razones sugeridas anteriormente, considere el impacto de una página o interfaz de usuario que no responde.</span> <span title="">El usuario no puede cerrar la aplicación si la lanzó por error.</span> <span title="">Si la aplicación se ejecuta en un navegador, es posible que el usuario obtenga una notificación diciendo "la aplicación no responde".</span> <span title="">Presentar algún tipo de interfaz, como una barra de progreso, para que el usuario sepa cuánto tiempo más tendrá que esperar mientras se inicia la aplicación es mejor que una interfaz incapaz de responder a las acciones del usuario.</span></p> + +<h2 id="Trabajar_con_Rendimiento_en_Mente">Trabajar con Rendimiento en Mente</h2> + +<p>Si está comenzando un proyecto de cero, generalmente es más sencillo escribir todo de la manera correcta, hacer que el código sea escrito para trabajar de manera asíncrona en mente. Hacer los cálculos iniciales en subprocesos en segundo plano cuando sea posible, crear tareas cortas para acelerar el tiempo de ejecución de los eventos de subprocesos importantes. Empezar a pintar en pantalla la interfaz gráfica para que el usuario sepa qué algo pasando y cuánto tiempo estará esperando. En teoría, de todos modos, debería ser bastante fácil diseñar una aplicación nueva para que inicie bien.</p> + +<p>Por otro lado, migrar una aplicación existente a la Web puede ser una tarea más complicada. Por ejemplo, una aplicación de escritorio no necesita escribirse de forma asíncrona porque generalmente el sistema operativo se encarga de eso, o aplicación que se está ejecutando actualmente es lo único que importa, dependiendo del entorno operativo. La aplicación original puede tener un ciclo principal que puede modificarse para operar de forma asíncrona (intentando ejecutar cada iteración del ciclo principal por separado); el inicio es a menudo un procedimiento monolítico continuo que puede ir actualizando de manera periódica la interfaz gráfica para indicar progreso.</p> + +<p>Si bien se puede usar los <a href="es/docs/Web/Guide/Performance/Usando_web_workers" title="/en-US/docs/DOM/Using_web_workers">Web workers </a>para ejecutar fragmentos de forma asíncrona códigos <a href="/es/docs/JavaScript">JavaScript</a> muy grandes y/o lentos, hay una gran advertencia: Web workers no tienen accesso a <a href="/es/docs/Web/API/WebGL_API" title="/en-US/docs/WebGL">WebGL</a> o audio, y no pueden enviar mensajes síncronos al hilo principal, por lo que no se puede hacer un proxy de esos APIs al hilo principal. <span title="">Todo esto significa que, a menos que se pueda extraer fácilmente los trozos de "cálculo puro" del proceso de inicio en Web workers, se va terminar teniendo que ejecutar la mayor parte o la totalidad del código de inicio en el hilo principal.</span></p> + +<p>Sin embargo, incluso código como ese puede ser hecho asíncrono, con un poco de trabajo.</p> + +<h2 id="Trabajando_de_Manera_Asíncrona">Trabajando de Manera Asíncrona</h2> + +<p>Algunas sugerencias que se pueden aplicar para hacer que el proceso de inicio de la aplicación se lo más asíncrona posible, sin importar si la aplicación es nueva o si se está migrando una que ya existe, son las siguientes:</p> + +<ul> + <li>Usar los atributos {{ htmlattrxref("defer") }} o {{ htmlattrxref("async") }} en los tag de script que la aplicación Web necesita. Esto permite que el interpretador de HTML no se vea forzado a esperar a que el código se haya descargado y ejecutado para continuar.</li> + <li>Si se necesita descodificar archivos de recurso (por ejemplo, descodificar archivos JPEG files y convertirlos en datos de textura para ser usados luegos en WebGL), este es un buen caso de uso para Web workers.</li> + <li>When dealing with data supported by the browser (por ejemplo, descodificar images), es mejor utilizar los descodificadores includos en el navegador o el dispositivo en lugar de utilizar un propio migrado del código existente. El descodificador incluído en el navegador es muy probablemente más rápido, y reduce la cantidad de código que se va a necesitar para iniciar la aplicación. Además, es posible que el navegador automáticamente pueda ejecutar en paralelo estos descodificadores.</li> + <li>Cualquier procesamiento de información que puede ejecutarse en paralelo debe ser ejecutada en paralelo. No trabaje con porciones de información de manera sequencial; es mejor ejecutarlas en paralelo, siempre que sea posible.</li> + <li>No incluya archivos de JavaScript o CSS que no son necesarios para la ruta crítica de iniciar la aplicación web. Cargue los recursos adicionales cuando sean necesarios.</li> + <li>Reduzca el tamaño de sus archivos JavaScript. Intente enviar la versión minificada de sus archivos a los navegadores y utilice mecanismos de compresión de recursos como Gzip o Brotli.</li> + <li>Utilice directivas (como preload, prefetch, preconnect) para ayudar al navegador a optimizar la carga de los recursos.</li> +</ul> + +<p>A mayor trabajo que se pueda realizar de manera asíncrona, la aplicación va a obtener mayor ventaja de procesadores multinúcleos.</p> + +<h3 id="Problemas_de_Migración">Problemas de Migración</h3> + +<p> </p> + +<p>Una vez que se realiza la carga inicial y el código principal de la aplicación comienza a ejecutarse, es posible que su aplicación esté programada para trabajar en un solo hilo, especialmente cuando es una migración. Lo más importante que se puede hacer para tratar de ayudar con el proceso de inicio del código principal es refactorizar el código en partes pequeñas que se pueden ejecutrar en trozos intercalados en múltiples llamadas del ciclo principal de su aplicación, para que el hilo principal pueda manejar las interacciones del usuario y similares.</p> + +<p>Emscripten proporciona una API para ayudar con esta refactorización; por ejemplo, puede usar emscripten_push_main_loop_blocker () para establecer una función que se ejecutará antes de que se permita que el hilo principal continúe. Al establecer una cola de funciones a ser llamadas en secuencia, puede administrar más fácilmente los bits de código en ejecución sin bloquear el hilo principal.</p> + +<p>Eso deja, sin embargo, el problema de tener que refactorizar su código existente para que realmente funcione de esa manera. Eso puede llevar algún tiempo.</p> + +<p> </p> + +<h3 id="¿Que_tan_asíncrono_debo_ser">¿Que tan asíncrono debo ser?</h3> + +<p>Vale la pena tener en cuenta que la mayoría de los navegadores suelen comenzar a quejarse de que un script está bloqueando el hilo principal aproximadamente a los 10 segundos. Idealmente, la aplicación no debería bloquear esa cantidad de tiempo, pero mientras se mantenga debajo de eso, debería estar bien. Sin embargo, tenga en cuenta que si alguien tiene una computadora más antigua y más lenta que la suya, ¡puede experimentar retrasos más prolongados que usted!</p> + +<h2 id="Otras_Sugerencias">Otras Sugerencias</h2> + +<p>Hay otras cosas además de ir asíncrono, que pueden ayudarlo a mejorar el tiempo de inicio de su aplicación. Estas son algunos de ellos:</p> + +<dl> + <dt>Tiempo de Descarga</dt> + <dd>Tenga en cuenta cuánto tiempo le llevará al usuario descargar los datos de su juego. Si su juego es realmente grande, muy popular o si tiene que volver a descargar contenido con frecuencia, debe intentar tener un servidor de alojamiento lo más rápido posible. También debe considerar utilizar mecanismos de compresión como Gzip o Brotli para que sean lo más pequeños posible.</dd> + <dt>Uso del GPU</dt> + <dd>La compilación de sombras y la carga de texturas en el GPU pueden llevar tiempo, especialmente para los juegos realmente complejos. Si bien esto también ocurre con los juegos nativos (que no son de la Web), todavía puede ser bastante molesto. Evita hacer esto sin mantener informado al usuario de que el juego, de hecho, todavía se está iniciando.</dd> + <dt>Tamaño de los Datos</dt> + <dd>Haz tu mejor esfuerzo para optimizar el tamaño de tus datos de juego; los archivos de menor nivel se descargarán y procesarán más rápido que los más grandes.</dd> + <dt>Factores Subjetivos</dt> + <dd>Cualquier cosa que pueda hacer para ayudar a mantener al usuario involucrado durante el proceso de inicio ayudará a que el tiempo parezca más rápido. Para los juegos, considere la posibilidad de reproducir música de fondo o mostrar una bonita pantalla de bienvenida. Entre cada cálculo, actualice su indicador de progreso, realice cambios en la pantalla o cualquier otra cosa que pueda hacer para ayudar al usuario a sentir que su aplicación está haciendo algo en lugar de quedarse sentado tranquilamente.</dd> +</dl> + +<h2 id="También_Podría_Interesarte">También Podría Interesarte</h2> + +<ul> + <li><a href="/es/docs/Web/Progressive_web_apps" title="/en-US/docs/Apps">Apps</a></li> + <li><a href="/es/docs/Games" title="/en-US/docs/Games">Games</a></li> +</ul> + +<div class="originaldocinfo"> +<h2 id="Original_Document_Information" name="Original_Document_Information">Información del Documento Original:</h2> + +<ul> + <li>Autor(s): Alon Zakai</li> + <li>Fuente: <a href="http://mozakai.blogspot.com/2012/07/bananabread-or-any-compiled-codebase.html" title="http://mozakai.blogspot.com/2012/07/bananabread-or-any-compiled-codebase.html">BananaBread (or any compiled codebase) Startup Experience</a></li> +</ul> +</div> + +<p> </p> |