Última revisión: 12 de diciembre de 2021
Estándar
El Web Performance Working Group es el equipo que plantea distintas especificaciones que utilizar a la hora de trabajar con mediciones y buenas prácticas de Web Performance.
- Navigation Timing – Recommendation
This document provides an interface for web applications to access timing information related to navigation and elements. - Page Visibility (Second Edition) – Recommendation
This specification defines a means for site developers to programmatically determine the current visibility state of the page in order to develop power and CPU efficient web applications. - Performance Timeline – Recommendation
This specification defines an interface for web applications to access timing information related to navigation and elements. It is used by other specifications, like User Timing. - Resource Timing Level 1 – Candidate Recommendation
This specification defines an interface for web applications to access timing information related to HTML elements. - Navigation Timing Level 2 – Working Draft
This document provides an interface for web applications to access timing information related to navigation and elements. - Beacon – Candidate Recommendation
This specification defines an interoperable means for site developers to asynchronously transfer data from the user agent to a web server, with the user agent taking the responsibility to eventually send the data. - High Resolution Time Level 2 – Recommendation
This specification defines a JavaScript interface that provides the current time in sub-millisecond resolution and such that it is not subject to system clock skew or adjustments. - Network Error Logging – Working Draft
Navigation Error Logging defines an API to store and retrieve error data related to the previous navigations of a document. - Resource Hints – Working Draft
Resource Hints provides hints that authors may use to assist the user agent in fetching resources to improve page performance. - Frame Timing – Group Note
Frame Timing helps web developers measure the performance of their applications by giving them access to frame performance data to facilitate smoothness measurements. - Server Timing – Working Draft
Server Timing, part of the performance timeline metrics, provides API access to request-response cycle performance metrics communicated from the server to the user agent. - Performance Timeline Level 2 – Working Draft
This specification extends the High Resolution Time specification by providing methods to store and retrieve high resolution performance metric data. - Preload – Candidate Recommendation
This specification defines the relationship of the HTML Link Element (). preload<link> - Cooperative Scheduling of Background Tasks – Proposed Recommendation
The requestIdleCallback method is a more appropriate way for scheduling background tasks during times when the browser would otherwise be idle. - Reporting API – Working Draft
The reporting API provides a generic reporting framework which allows Web developers to associate a set of named reporting endpoints with an origin. Various platform features (like Content Security Policy, Network Error Reporting, and others) will use these endpoints to deliver feature-specific reports in a consistent manner. - Page Visibility Level 2 – Proposed Recommendation
Page Visibility defines a means to programmatically determine the visibility state of a document. This can aid in the development of power and CPU efficient web applications. - User Timing Level 2 – Recommendation
This specification defines an interface to help web developers measure the performance of their applications by giving them access to high precision timestamps. - Resource Timing Level 2 – Working Draft
This specification defines an interface for web applications to access the complete timing information for resources in a document. - Long Tasks API 1 – Working Draft
This document defines an API that web page authors can use to detect presence of “long tasks” that monopolize the UI thread for extended periods of time and block other critical tasks from being executed – e.g. reacting to user input. - Paint Timing 1 – Working Draft
This document defines an API that can be used to capture a series of key moments (First Paint, First Contentful Paint) during pageload which developers care about. - Device Memory – Working Draft
This document defines a HTTP Client Hint header to surface device capability for memory i.e. device RAM, in order to enable web apps to customize content depending on device memory constraints. - User Timing Level 3 – Working Draft
This specification defines an interface to help web developers measure the performance of their applications by giving them access to high precision timestamps. - Timing Entry Names Registry – Working Draft
This registry is intended to provide a central location for enumerating identified interface types of PerformanceEntry objects, which contain various data metrics for the the full lifecycle of a web application.
Herramientas
Existen multitud de herramientas que pueden ayudarte con las mejoras de Web Performance. Aquí algunas (ordenadas alfabéticamente):
- Apache JMeter permite hacer pruebas Web, SOAP, bases de datos…
- OctaGate SiteTimer permite monitorizar el tiempo de descarga de cada uno de los elementos de una página.
- PageSpeed para Apache HTTP es un módulo que lleva la configuración por defecto de muchas opciones (compresión, agrupar CSS y JS…).
- PageSpeed para nginx es un módulo que lleva la configuración por defecto de muchas opciones (compresión, agrupar CSS y JS…).
- PageSpeed Insights hace un análisis de los distintos elementos de tu sitio con tiempos agregados y avisos.
- Telerik Fiddler es un Web Debugging Proxy que permite monitorizar todo el tráfico contra Internet.
- Test My Site analiza la versión móvil de tu sitio y te da información para mejorarla.
- WebPageTest permite el análisis del rendimiento de sitios web desde múltiples puntos del mundo y simulando múltiples dispositivos.
- YSlow analiza páginas web y sugiere formas de mejorar el rendimiento, en base a un conjunto de 34 reglas de optimización con las que puedes mejorar el rendimiento de tu web y hacerla considerablemente más rápida.
Haciendo un primer análisis
Para hacer un análisis lo primero que hemos de decidir es qué vamos a analizar. Esto significa que no solo hemos de elegir la página principal de nuestro sitio, sino también otras páginas de muestra del resto de plantillas del sitio.
Por ejemplo, en un blog podríamos tomar de base la página principal, la página de una categoría, una entrada y una página estática. En un comercio electrónico podríamos tomar la página principal, el listado de productos de una categoría, una ficha de producto, la pantalla de pago o el carrito, y una página estática (términos y condiciones, contacto…).
Los primeros análisis se podrían hacer en 3 lugares distintos. El primero es un análisis rápido en las herramientas para desarrolladores que incorporan todos los navegadores (Chrome, Edge, Firefox…). Aquí veremos el tiempo de carga en un entorno controlado y lo más parecido a un usuario. Es muy recomendable tomar muestras en distintos navegadores, ya que cada uno puede trabajar de una forma distinta a la hora de cargar y procesar un sitio.
La segunda herramienta para probar, similar a la que podemos tener en nuestro navegador, es la de WebPageTest. Este sistema emula un navegador web (Firefox, Chrome…) pero en distintas localizaciones del mundo y con distintas conexiones.
Para acabar, podemos usar la herramienta PageSpeed Insights que nos dará otra serie de datos mucho más calculados y con menos datos en crudo.
En cualquier cosa, en estas herramientas siempre se han de interpretar los datos, ya que cada uno de ellos puede significar una cosa distinta y hay que contextualizarlos. Sobre todo, hay que poner siempre en contexto las peticiones más lentas que, habitualmente, son elementos externos sobre los que no se pueden tener control, ya que suelen ser scripts third-party.
