Post Top Ad

Your Ad Spot

miércoles, 6 de mayo de 2020

Cómo mejorar la velocidad de la página de principio a fin (Guía avanzada)

Hay muchas herramientas para probar la velocidad de la página y muchas métricas diferentes para apuntar. ¿Pero entiendes cómo funcionan esas optimizaciones o si realmente harán que tu sitio web sea más rápido?
La velocidad de la página es un tema complejo. Muchos de los artículos existentes le brindan una lista de acciones a tomar o complementos para instalar para ayudar con diferentes aspectos de la velocidad. Eso está bien, pero no todos los sitios son iguales. Entonces, en esta publicación, lo ayudaré a comprender cómo funciona la velocidad de la página y qué acciones tomar para su sitio en particular.
Dicho esto, si no es técnico y solo espera instalar un complemento / módulo para acelerar su sitio, aquí hay algunos que deberían ayudar:
WordPress:
  • WP Rocket (pago)  + un complemento de optimización de imagen , o:
  • Optimización automática  + un complemento de caché
Drupal
  • AdvAgg  + un módulo de optimización de imagen
Ahora, de vuelta al negocio. Aquí está todo lo que voy a cubrir:
  • ¿Qué es la velocidad de la página?
  • Por qué debería importarle la velocidad de la página
  • ¿Qué tan rápido debe cargar mi página?
  • Cómo se construye una página
  • Prueba de velocidad de página y herramientas
  • Estimando el impacto de los cambios
La velocidad de la página es la cantidad de tiempo que tarda en cargar una página web. Es difícil asignar un solo número a la velocidad de la página porque muchas métricas capturan elementos de la carga de la página de diferentes maneras, para diferentes propósitos y con diferentes condiciones de prueba.
Google ha renovado recientemente la velocidad de la página con la velocidad móvil convirtiéndose en un factor de clasificación , un Informe de velocidad  en la Consola de búsqueda de Google y Chrome anunciando que pueden marcar sitios que son lentos , pero ¿sabías que la velocidad de la página ha sido un factor de clasificación? para Google desde 2010 ?
Estas son las razones por las que debería preocuparse:
  • Impactos en la experiencia del usuario . Desea que los visitantes tengan una experiencia rápida y fluida. Cualquier retraso o retraso en sus acciones es notable.
  • Análisis de Impactos . En términos generales, un sitio más rápido registrará más visitantes porque la etiqueta de análisis se cargará antes. Si una persona se va antes de que se active la etiqueta, no se registrará en el sistema de análisis.
  • SEO ? La actualización de velocidad solo afecta a los sitios más lentos según el anuncio oficial .
Hay muchos estudios que muestran que si aumenta la velocidad de la página, verá aumentos en cosas como el tráfico orgánico, el porcentaje de visitas por clic en los anuncios, más visitantes en general y muchos otros beneficios. WPO Stats  tiene muchos estudios de ejemplo sobre mejoras en la velocidad de la página.
Sin embargo, advertiré que muchos de estos estudios pueden ser un poco engañosos. A menos que haya sido extremadamente lento antes, Google dice que mejorar la velocidad de la página no debería afectar su clasificación.
Entonces, ¿por qué podrías ver más visitantes?
La respuesta es que la etiqueta de análisis probablemente se activó antes que antes y pudo registrar a más personas antes de que salgan de una página.
No hay umbral oficial . Una de las recomendaciones comunes es que su sitio se cargue en menos de tres segundos. Eso probablemente proviene de un estudio de Google  que dice que el 53% de los visitantes móviles abandonan una página que tarda más de tres segundos en cargarse.
Esta recomendación también se basa probablemente en la métrica del índice de velocidad, de la que hablaremos más adelante, pero esa es solo mi especulación basada en lo que era una medida popular en el momento del estudio. No creo que Google haya mencionado alguna vez una métrica particular al dar un número para la velocidad de la página. Por lo general, las recomendaciones de los representantes de Google son genéricas, como "hacer que los sitios sean rápidos para los usuarios" o "hacer los sitios lo más rápido posible".
Para comprender cómo mejorar la velocidad de su página, necesita saber cómo un navegador construye una página. Para esto, vamos a ver principalmente los gráficos de Cascadas para ver qué recursos se están cargando. También puede ver esto en su navegador al hacer clic con el botón derecho> Inspeccionar> y abrir la pestaña Red al cargar una página.
NOTA AL MARGEN.
Voy a utilizar https://www.webpagetest.org/  para muchas de las imágenes, y vincularé a las pruebas y enumeraré las configuraciones donde corresponda.

Establecer conexiones

El verde, naranja y morado a continuación representan el tiempo que lleva establecer una conexión con el sitio web. Revisaré cada color a continuación y lo que representa.
1 establecer conexiones 3
Gráfico de cascada para la página del tema TwentyTwenty WordPress de WebPageTest.org ( verlo aquí ). Localización: Dulles, VA . Dispositivo: Moto G4 . Navegador: Chrome. Velocidad: 3GSlow.

DNS (verde)

El Sistema de nombres de dominio ( DNS ) se considera la guía telefónica de la web. Usted le da a su navegador un nombre de sitio web, y verifica con un servidor DNS para obtener una dirección IP (una etiqueta de ubicación) que le indica dónde está alojado el sitio web. Es como almacenar un contacto en su teléfono, por lo que solo tiene que saber el nombre y no el número de teléfono.
La mayoría de las veces, su DNS estará con su registrador de dominio (donde compró el dominio) o con su Content Delivery Network ( CDN ).
Es importante destacar que no todos los proveedores de DNS se crean de la misma manera. Si cada milisegundo es importante para usted, puede considerar usar un proveedor de DNS diferente Según DNSPerf , Cloudflare tiene una velocidad de consulta promedio de 12.6 ms, mientras que otros como GoDaddy (46.04 ms) y Rackspace (90.38 ms) son más lentos en promedio. Sin embargo, estos números no son una representación completamente precisa ya que el DNS se puede almacenar en caché (almacenar temporalmente) en el navegador cuando ya ha visitado un sitio web. La cantidad de tiempo que se almacena en caché se conoce como TTL (Time to Live). Mientras el caché aún esté activo, el navegador no tendrá que conectarse al servidor DNS para saber a dónde ir para acceder al sitio web.

Conectar (naranja)

Aquí es donde el navegador está estableciendo una conexión con el servidor de alojamiento. El Protocolo de control de transmisión / Protocolo de Internet ( TCP / IP ) es complicado, pero solo piense en cómo llegar al trabajo. Es probable que no sea una línea recta; tienes que hacer giros, y habrá áreas con mayor tráfico. Incluso puede cambiar de ruta o hacer algunos giros incorrectos. Así es como funciona esto; está enrutando desde su navegador al servidor y viceversa.
Si el tiempo de conexión es largo, podría ser uno de los muchos problemas. En conexiones inestables, la pérdida de paquetes puede ocurrir y tendrá que ser reenviada. Esto es similar a perder su turno en una rotonda y tener que dar la vuelta nuevamente. El problema también podría estar en el enrutamiento de la solicitud a través de la red. Cuántos saltos tiene que tomar, qué tan lejos tiene que llegar, cuánto tráfico hay en la red son similares a cuántos giros debe tomar, a qué distancia del trabajo se encuentra y cuántos otros automóviles están en la carretera eso podría ralentizarlo. También hay una capacidad de conexión y limitación de velocidad en el servidor, que sería similar a un túnel que solo permite tantos automóviles a la vez.
Muchos de estos problemas se resuelven acortando la distancia al servidor y utilizando un enrutamiento más inteligente, lo que pueden hacer muchos CDN. Con una red de servidores en todo el mundo, los visitantes generalmente pueden conectarse a uno cercano. Algunos proveedores de CDN también gestionan grandes cantidades de solicitudes de Internet y pueden ver en tiempo real dónde puede haber cuellos de botella (tráfico). Si ven una opción más rápida, pueden redirigir el tráfico, tal como un GPS lo redirigiría alrededor de un atasco.

Capa de sockets seguros ( SSL ) (púrpura)

Para los sitios que establecen una conexión segura ( HTTPS ), aquí es donde el navegador y el servidor acuerdan la versión del protocolo TLS (Seguridad de la capa de transporte), el conjunto de cifrado (nivel de seguridad) y la verificación del certificado (para asegurarse de que el sitio sea el uno dice que es).
Puede estar pensando que puede hacer que su sitio web sea más rápido simplemente no utilizando HTTPS . Eso es parcialmente cierto, al menos para la parte de conexión. Pero hay otros beneficios de estar en HTTPS como el hecho de que los navegadores no le permiten usar HTTP / 2 ( H2 ) sin HTTPS . H2 tiene algunas ventajas como las conexiones persistentes, por lo que no tiene que seguir abriendo una nueva conexión para archivos en el mismo servidor. Los encabezados dentro de esas solicitudes también son más pequeños que en HTTP /1.1, y se pueden transferir múltiples archivos simultáneamente. En la mayoría de los casos, los sitios que usan HTTPS y H2 serán más rápidos que los sitios en HTTP.
En general, las ganancias más importantes que obtendrá aquí provienen de actualizar su protocolo ( TLS 1.3 es más rápido que TLS 1.2, por ejemplo) e implementar HTTP Strict Transport Security ( HSTS ), que le dice al navegador que siempre use una conexión segura. El navegador cambia las solicitudes de HTTP a HTTPS sin tener que contactar al servidor y hacer una redirección. En la imagen a continuación, la redirección de HTTP a HTTPS y el tiempo que tomó se eliminarían mediante el uso de HSTS .
2 tomas seguras capa 3
Es posible que incluso desee considerar el uso de HTTP / 3  para conexiones aún más rápidas. Sin embargo, el soporte para este protocolo aún se encuentra en las primeras etapas y, al menos al momento de la redacción, probablemente todavía no sea una opción viable.
IMPORTANTE: DISPOSITIVO, UBICACIÓN Y MATERIA DE RED
Considere esto, conectarse a un sitio web en un teléfono inteligente de grado medio con una conexión 3G lenta toma ~ 2 segundos. En el mismo teléfono con una conexión LTE , se reduce a ~ 0,41 segundos. En una computadora de escritorio con velocidades normales, es menos de 0.1 segundos para hacer esa conexión.
Tenga esto en cuenta si ve tiempos de conexión más largos, ya que puede deberse al ancho de banda limitado o la potencia de procesamiento del dispositivo de prueba. Estos factores, junto con el almacenamiento en caché, son importantes. Pueden ayudarlo a explicarle a alguien que podría sacar su último teléfono inteligente, conectado a WiFi, con todos los archivos necesarios para cargar la página ya almacenada en caché en su dispositivo (hablaremos de esto en otra sección) de la forma en que están experimentando el sitio está en condiciones ideales y no como la mayoría de las personas lo experimentarán.

Descargar y procesar HTML

El código HTML de una página es lo que inicialmente descarga un navegador. Esta es la información que ves cuando haces clic derecho en un sitio web y vas a "Ver código fuente de la página". Una vez que se ha establecido una conexión y el navegador recupera el primer bit de información del servidor, llegamos al Tiempo hasta el primer byte ( TTFB ), que es la medida típica para el tiempo de respuesta inicial. Como lo representan las líneas naranjas a continuación, este es el tiempo desde el inicio de la solicitud HTML (azul claro) hasta el momento en que el HTML comienza a descargarse (azul oscuro).
3 descargando html 3
Si hay una demora para TTFB , podría deberse a consultas en la base de datos, recursos del servidor, espera de que se complete un Render del lado del servidor ( SSR ) u otras cosas típicamente involucradas con la creación de contenido dinámico. El tiempo de descarga dependerá de cosas como la conexión y el tamaño del archivo.
Aquí también es donde el navegador también comienza a construir una página. Cuando se descarga el HTML , el navegador lo analiza en el Modelo de Objetos del Documento ( DOM ), que es cómo una computadora entiende la estructura del contenido. Ese proceso de análisis utiliza el hilo principal del navegador para procesar las acciones del usuario y pintar la página, ejecutar JavaScript y realizar el diseño, los reflujos y la recolección de basura. Por ahora, solo sepa que este hilo principal existe y maneja muchas tareas diferentes. Cubriremos esto un poco más tarde.
Si ve una brecha entre HTML y la siguiente solicitud, la causa más probable es que la CPU está ocupada procesando el HTML para construir el DOM . Dado que es la CPU , esto depende nuevamente del dispositivo que se esté utilizando, por lo que puede probar con un dispositivo más potente para ver si esa brecha aún existe.
Para el HTML y otros tipos de archivos como CSS y JavaScript, puede reducir el tiempo usando menos código, minificación para eliminar caracteres innecesarios como comentarios y espacios en blanco del código, y compresión para reducir el tamaño de los archivos. El punto es hacer que la descarga del archivo sea más pequeña para que esta parte de la carga sea más rápida. Sin embargo, no hay una sola forma de hacer minificación y compresión. En muchos casos, esto es manejado por el CDN o el servidor (Apache o Nginx son servidores comunes), o por un complemento / módulo / paquete. Puede encontrar más información sobre la implementación de la compresión aquí  y la minificación aquí .

Manejo de conexiones adicionales

Cuando se haya descargado el HTML , se procesarán las referencias a otros archivos y otros servidores, y se iniciarán nuevas conexiones. Esto es típicamente donde otros archivos como JavaScript, CSS , imágenes y fuentes se agregan a la mezcla. Las cosas pueden volverse locas aquí, ya que algunos archivos hacen referencia a otros archivos y comenzamos a encadenar conexiones y descargas de archivos. Eche un vistazo al Mapa de solicitudes a continuación para Forbes.com. Cada punto es una solicitud de archivo individual, y cada línea es donde un archivo hace referencia a otro archivo que debe descargarse. En general, son 363 solicitudes en 128 conexiones.
requestmap https www.forbes.com 3
Fuente: RequestMap

Utilice el mismo servidor para solicitudes cuando sea posible

Solía ​​ser una buena práctica alojar recursos en dominios sin cookies que no eran los mismos que el dominio principal, y a veces sería beneficioso usar múltiples dominios (un proceso llamado fragmentación de dominio) debido a los límites de solicitud de conexión establecidos por el navegador.
Desde HTTP / 2, esa no ha sido una práctica recomendada. Debe usar el mismo servidor para las solicitudes, si es posible.
Por ejemplo, tome cdn.ahrefs.com  en la tabla de cascada a continuación.
4 mismo servidor 3
Si ese archivo estuviera alojado en ahrefs.com, entonces ni siquiera tendría que hacer la conexión. Se está retrasando por el momento de establecer la conexión DNS , conectarse y negociar el apretón de manos de seguridad. Sin los aros adicionales para saltar, tendríamos el archivo antes, lo que significa que la página se cargaría aún más rápido.
Sin embargo, aunque el autohospedaje de muchos archivos, como las fuentes, puede generar ganancias, puede haber otras compensaciones como el almacenamiento en caché (almacenamiento de una copia de un archivo) donde los navegadores a veces pueden tener recursos comunes en caché. Por ejemplo, si visité un sitio web que llamaba a una fuente de Google Fonts y luego fui a otro sitio web que usaba la misma fuente, podría tener ese archivo almacenado en caché localmente y no tener que volver a descargarlo.

Use Preconnect o DNS-Prefetch (si usa otro servidor)

Si va a utilizar un servidor diferente, preconéctese a los servidores que contienen los archivos necesarios al principio de la carga de la página. Esto hará que la conexión a otro servidor sea más temprana de lo normal. Vea a continuación cómo se inicia una de las conexiones para Amazon antes de que el HTML termine de procesarse.
5 preconexión dns prefetch 3
Ejemplo de código:
<link rel="preconnect" href="https://site.com">
También hay captación previa de DNS si solo desea manejar esa parte de la conexión antes. La parte verde ( DNS ) se conectaría temprano, pero el resto de la conexión ocurrirá más tarde. DNS-prefetch tiene mejor soporte  que preconnect , pero si observa las estadísticas de uso actuales, la diferencia sería insignificante. La preconexión generalmente es mejor si sabe que algo de ese servidor necesita cargarse antes para que la página funcione. Sin embargo, debido a que la preconexión requiere más trabajo para el enrutamiento y la seguridad (el naranja y el morado), también va a requerir un poco más de recursos desde el principio.
Ejemplo de código:
<link rel="dns-prefetch" href="//asset1.com">

Cómo los navegadores procesan una página

Antes de continuar y analizar las opciones de optimización, creo que es mejor entender un poco sobre cómo un navegador representa una página. Ahora tenemos otros archivos como CSS , JavaScript, imágenes y fuentes, y el navegador tiene que convertirlos, junto con el HTML , en algo útil. Este es un proceso dinámico con nuevos archivos que se introducen, descargan, analizan y reorganizan constantemente para construir la página. Este proceso se denomina comúnmente Ruta de representación crítica y tiene este aspecto:
  1. HTML se procesa en el árbol DOM que mencionamos anteriormente
  2. CSS se analiza en el Modelo de objetos CSS ( CSSOM ), que le dice al navegador cómo se peina, rellena, colorea, dimensiona, etc.
  3. El CSSOM + DOM juntos forman lo que se llama el árbol de renderizado .imagen pegada 0 61
  4. El diseño ocurre, que es el procesamiento donde cada elemento estará dentro de la ventana del navegador en función de lo que está en el árbol de renderizado.imagen pegada 0 58
  5. Los píxeles se pintan en la pantalla, por lo que en lugar de una pantalla blanca, verá colores, formas, texto e imágenes.
NOTA AL MARGEN.
 Un hecho divertido revelado por Martin Splitt  de Google es que Googlebot ahorra tiempo y recursos al no pintar los píxeles de una página. Tienen la información que necesitan después del diseño.
El objetivo debe ser obtener los elementos necesarios lo antes posible para construir la vista inicial lo más rápido posible. El tiempo de carga visible es la vista percibida por la gente de la velocidad de una página, es decir, qué tan pronto el contenido aparece en la pantalla para ellos. Lo que más impacta esto es cómo se cargan los recursos. Por lo general, es responsabilidad del CMS o JavaScript Framework ayudar al navegador a priorizar cuándo / qué / cómo cargar los recursos en qué orden para que el sitio parezca más rápido. Más sobre esto en un momento.
También desea mantener las cosas simples y evitar cálculos complejos y muchos cambios durante la fase de diseño. Google tiene una guía más centrada en el desarrollador para eso aquí , y otra sobre la simplificación del proceso de pintura .

Métricas de carga visual:

  • First Paint ( FP )  : el navegador muestra cualquier cosa por primera vez.
  • First Contentful Paint ( FCP ) : el navegador muestra algo del DOM (Modelo de objetos de documento), que podría ser texto, una imagen, etc.
  • Primera pintura significativa ( FMP )  : elementos más importantes cargados visualmente.
  • Pintura contenta más grande ( LCP )  : elemento más grande sobre el doblez cargado.
  • Visualmente completo  : la página se carga visualmente.
  • Índice de velocidad : una puntuación calculada para la carga visual que tiene en cuenta múltiples puntos en el tiempo.
  • Desplazamiento de diseño acumulativo ( CLS )  : mide la cantidad de elementos que se mueven en la ventana gráfica durante la carga o la estabilidad del diseño. Hay una buena guía para las causas de CLS aquí .
Addy Osmani @addyosmani
"If you can't measure it, you can't improve it" http://web.dev/metrics  covers how to measure modern web performance metrics & optimize for them.
View image on Twitter
1,456
5:30 AM - Jan 31, 2020
Twitter Ads info and privacy
383 people are talking about this

Ver la carga visual junto con el gráfico de cascada

En la sección Resumen en WebPageTest , si habilitó la grabación, debería tener una columna de Video en la tabla principal con "Vista de tira de película". En esta vista, la línea roja en la parte superior con las instantáneas visuales está en el mismo punto que la línea roja en la parte inferior de la cascada.
6 cascada de carga visual 3
Al mover la línea roja a diferentes puntos en la carga visual, debería poder ver lo que se acaba de cargar en la cascada que puede haber permitido que se visualicen visualmente diferentes elementos. Esto puede ayudarlo a determinar qué archivos puede necesitar priorizar.
Por ejemplo, si ve que la mayor parte de su página está cargada, excepto el texto, pero justo después de que se carga una fuente y aparece el texto, entonces es una buena indicación de que la fuente era necesaria para mostrar el texto. También podrá saber qué imágenes pueden necesitarse antes con diferentes ventanas gráficas simplemente mirando las capturas de pantalla generadas.
En la parte inferior de este cuadro hay información adicional, como la utilización de la CPU , el ancho de banda, la actividad en el subproceso principal del navegador y la interactividad. Todos estos gráficos nuevamente dependen del dispositivo y el tipo de conexión. La información se puede utilizar para ayudar a solucionar diferentes problemas. Por ejemplo, tal vez simplemente se está descargando demasiado, lo que mantiene el ancho de banda en el punto más alto. O tal vez hay un script que usa toda la CPU para un determinado dispositivo, lo que puede causar retrasos.
imagen pegada 0 65

Tipo de archivo CSS

Donde la velocidad de la página se complica es que, en muchos casos, no hay una sola forma correcta de hacer las cosas. La mayoría de los métodos tienen compensaciones, y algunos son más complejos de implementar y mantener. Tienes que decidir qué es lo más fácil, rápido y mejor para ti en tus circunstancias.
Al mirar los archivos CSS , están bloqueados de forma predeterminada, lo que significa que deben descargarse y procesarse antes de que una página muestre contenido al usuario. Si almacena en caché (almacene una copia del archivo, que se trata más adelante en el artículo), ese archivo puede reutilizarse para las cargas de página posteriores. Eso significa que no tendrá que volver a descargarse, y las siguientes vistas deberían ser más rápidas.
La mayoría de las herramientas de velocidad prueban con la primera vista, por lo que mucho de lo que ve en una herramienta como PageSpeed ​​Insights  es representativo de un usuario nuevo que solo ve una página y no alguien que visita varias páginas o vuelve a su sitio web a menudo . Su objetivo debe ser optimizar tanto la primera vista como las vistas posteriores para los usuarios.

Cargando CSS asincrónicamente

Desea cargar el código importante lo antes posible, y hablaremos de algunas opciones para eso en un segundo, pero la otra parte de esto es que desea que el CSS no bloquee el render. Para hacer esto, queremos cargar las hojas de estilo necesarias más adelante en el proceso de carga como un tipo de medio diferente, que luego se aplica a todos los tipos. Está engañando al navegador al abusar de cómo manejan la carga de atributos de elementos de enlace específicos. Lo que va a hacer es cargar el CSS sin bloquear la representación (porque en este caso, le estamos diciendo al navegador que esta hoja de estilo es para imprimir y no realmente para esta versión de la página), y luego aplicarla a todos los tipos de medios (cosas que no se imprimen) después de que se carga.
Por ejemplo, esto:
<link rel="stylesheet" href="/my.css">
Se convierte en esto:
<link rel="stylesheet" href="/my.css" media="print" onload="this.media='all'">
Puede usar esto con todas sus referencias CSS . La desventaja es que los usuarios pueden experimentar algunos flashes / re-estilos ya que algunos elementos de la página pueden pintarse antes de aplicar el CSS . Entonces, cuando se aplica el CSS , la pantalla puede cambiar dónde y cómo se muestran las cosas.

En línea

Inline toma el código necesario para representar el contenido por encima del pliegue y lo entrega con la respuesta HTML en lugar de un archivo separado. Por lo general, esta será la forma más rápida de acortar el tiempo que lleva renderizar la vista inicial.
La forma más fácil de pensar en esto es tomar partes críticas de los archivos CSS y JS y colocarlo directamente en el HTML . El HTML inicial tarda un poco más en descargarse y analizarse, pero el renderizado de la página ahora puede realizarse antes de que se descarguen todos los demás archivos.
imagen pegada 0 59
La alineación probablemente le proporcionará el renderizado más rápido en la carga de la página inicial, pero la compensación ha sido tradicionalmente con el almacenamiento en caché. El código cargado en el HTML no se puede reutilizar desde la memoria caché, por lo que normalmente cargaría parte del código dos veces: una con el HTML y otra vez en el archivo normal que normalmente se almacena en caché. Pero si incluía código en línea para cada página, eso también significaba que las páginas posteriores también tendrían código adicional. Esto es avanzado e implica el uso de trabajadores de servicio , pero puede tener tanto en línea como en caché . Combinado con hacer que el resto del CSS sea asíncrono como mencionamos anteriormente, este es más o menos un estado ideal.
Recuerde que puede minificar el código CSS en línea Como se mencionó en la sección HTML anterior, esto elimina algunos espacios innecesarios y caracteres adicionales para hacer que el código sea más pequeño y más rápido para descargar.
Probablemente no desee incluir todo el contenido de todos los archivos. Sea considerado y solo contenido crítico en línea. Técnicamente, puede alinear todos los CSS y JS e incluso las fuentes e imágenes, pero terminará con una descarga gigante de HTML donde no se usa gran parte del código. Eso realmente hace que su sitio web sea más lento. Si tiene algunos archivos más pequeños de solo unos pocos KB y desea incluirlos en línea, probablemente esté bien hacerlo.
CSS crítico en línea a escala:
Vas a querer un sistema automatizado en lugar de hacerlo para cada página. Puede tener sentido en línea solo el CSS para la página de inicio en los temas de WordPress, ya que generalmente tiene una hoja de estilo diferente a otras páginas. Por lo general, habrá algún complemento / módulo / paquete o una versión de CSS crítico o crítico Estos paquetes existen para cualquier ejecutador de tareas o empaque que pueda estar utilizando como Grunt, Gulp, Webpack o Framework como React, Angular, Vue, e incluso puede encontrar tutoriales específicos para WordPress o Drupal o incluso páginas codificadas a mano. Enviarán un navegador sin cabeza a la página para determinar qué CSSes realmente crítico para la carga de la página en diferentes tamaños, y le da el código o lo divide en elementos críticos y no críticos para que pueda cargarlos de manera adecuada. Algunos ejemplos:
Grunt:
https://github.com/filamentgroup/grunt-criticalcss
https://www.npmjs.com/package/grunt-critical-css
https://github.com/bezoerb/grunt-critical
Gulp:
https://github.com/addyosmani/critical
https://www.npmjs.com/package/gulp-critical-css
Paquete web:
https://github.com/anthonygore/html-critical-webpack-plugin
https://github.com/GoogleChromeLabs/critters
https://github.com/anthonygore/html-critical-webpack-plugin
https: / /www.npmjs.com/package/critical-css-webpack-plugin
Reaccionar:
https://www.npmjs.com/package/react-critical-css  
https://github.com/addyosmani/critical-path-css-tools  
https://github.com/sergei-zelinsky/react- critico-css 
Angular:
https://github.com/addyosmani/critical-path-angular-demo 
Vue:
https://github.com/anthonygore/vue-cli-plugin-critical  
https://vuejsdevelopers.com/2017/07/24/critical-css-webpack/ 
Drupal:
https://www.fourkitchens.com/blog/article/use-gulp-automate-your-critical-path-css/ 
WordPress:
https://joe-watkins.io/javascript/inline-critical-css-with-wordpress/  
https://wordpress.org/plugins/wp-criticalcss/
Codificado a mano:
https://www.sitelocity.com/critical-path-css-generator  
https://jonassebastianohlsson.com/criticalpathcssgenerator/ 

Precarga

Si no va a alinear el CSS crítico , podría decirse que la siguiente mejor opción es usar Preload. La precarga recupera solicitudes más temprano en la carga, obteniendo los recursos esenciales necesarios para mostrar la página más rápido de lo habitual. La precarga establece la prioridad del navegador para los activos precargados como alta y los carga de forma asincrónica, para que no bloqueen la representación. También funciona en todos los dominios.
El navegador da prioridad a cada solicitud de un archivo. La idea es obtener los archivos necesarios para mostrar el contenido de la mitad superior de la página antes (con mayor prioridad) y diferir los que no sean necesarios hasta más adelante en el proceso. Puede ver la prioridad dada a los archivos en la pestaña Red en Herramientas de desarrollo de Chrome. Simplemente haga clic derecho en la barra, seleccione Prioridad y agréguela como una columna.
7 precarga prioridad 3
Lo que hará es tomar un archivo que puede haber comenzado a descargar más tarde y descargarlo lo antes posible. Una vez más, el otro beneficio es que cuando el archivo precargado hubiera sido bloqueado anteriormente, ya no será el caso.
Addy Osmani @addyosmani
New: Loading performance pro-tips for <link rel="preload">, prefetch & priorities in Chrome: https://medium.com/@addyosmani/preload-prefetch-and-priorities-in-chrome-776165961bbf 🔥
View image on Twitter
620
5:38 PM - Mar 27, 2017
Twitter Ads info and privacy
324 people are talking about this
En combinación con lo que mencionamos anteriormente para hacer CSS asíncrono, la precarga simplemente agrega otra línea que está destinada a obtener el archivo más rápido al establecer la prioridad del navegador más alta de lo normal. Esto también funcionará para navegadores donde no se admite la precarga .
Ejemplos de código:
<link rel="preload" href="/my.css" as="style">
<link rel="stylesheet" href="/my.css" media="print" onload="this.media='all'">
Elegir qué archivos precargar
Por lo general, tendrá el archivo de tema principal que contiene una gran cantidad de CSSpara el sitio web. Los desarrolladores a menudo nombran esto después del tema, o lo llaman "estilo", o a veces lo nombran después del sitio web en sí. Si tiene problemas para identificar este archivo o cree que otros archivos también deben ser precargados, entonces la forma más fácil de verificarlo es mediante el uso de la función de bloqueo de solicitud en Chrome Dev Tools. Abra la pestaña Red y cargue una página para ver los archivos solicitados. Puede hacer clic con el botón derecho en estos para agregarlos a la lista de bloqueo. Cuando vuelve a cargar una página, si la página todavía se ve normal, entonces probablemente no bloqueó un archivo necesario para el contenido del pliegue anterior. Cuando obtiene uno de estos que rompe el aspecto de la página, es una indicación de que es necesario para mostrar el contenido sobre el pliegue y es un archivo que desea precargar.
8 bloque de solicitud url 3
Cosas que debe saber sobre la precarga
  1. Necesita un origen cruzado en las fuentes o obtendrá una carga doble del archivo.
  2. Todavía necesita las llamadas de archivo normales para JS + CSS , así que no las elimine.
  3. Puede precargar una fuente incluso si se llama en otro archivo como un archivo CSS .
  4. Tenga cuidado de cuánto precarga. Puede encontrarse con problemas al intentar precargar demasiados archivos.

Servidor Push

Esto era parte de la especificación HTTP / 2 ( H2 ). Permite que un servidor entregue un archivo sin que se solicite. Entonces, en lugar de una cadena que podría ser HTML > CSS > Fuente, esto permite que un sitio diga que voy a necesitar esa fuente, solo envíela.
Server Push es problemático, y normalmente lo recomiendo, pero si eres un gran desarrollador o tienes acceso a uno, puedes intentarlo. Solicita archivos del servidor en la misma conexión que la solicitud de página. La inserción del servidor puede cargar activos dos veces. Existe una solución alternativa al usar cookies y verificar si ya ha enviado activos a los usuarios, pero es una implementación compleja. Hay otro problema relacionado con problemas de conexión que puede hacer que los archivos no se carguen en absoluto. Con todo el trabajo adicional, es posible que aún no vea ganancias significativas sobre la precarga porque los navegadores verifican la caché de la página (donde está la precarga) antes de la caché de inserción.

JavaScript tipo de archivo

JavaScript también puede ser complejo, con muchas opciones y muchas consideraciones. A veces se usa para proporcionar funcionalidad, a veces se usa para extraer el contenido principal, y a veces incluso se usa para hacer cambios en el CSS . Además, cierto código puede necesitar otro código para ejecutarse correctamente. Estos se conocen como dependencias, y cambiar la forma en que se carga JavaScript puede terminar rompiendo algunas funcionalidades de la página.
Si JavaScript desempeña un papel fundamental en el contenido o el estilo de la página, o si es el sistema central, como es el caso con muchos marcos de JavaScript, muchas de las mismas reglas que CSS se aplican en cuanto a la alineación y la precarga. Sin embargo, también tiene la opción de Representación del lado del servidor ( SSR ) . Esto procesa el código y genera una instantánea. Por ejemplo, si se usa JavaScript para completar elementos en la página o para el menú, es posible que desee esta información más temprano en la carga o reducir parte de la carga del navegador del cliente, es posible que desee utilizar una solución SSR .
La forma más fácil de ver si se necesita JavaScript en la página es hacer clic en el candado en Chrome y abrir la configuración del sitio. Verá una lista de permisos, uno de los cuales es JavaScript, donde puede permitirlo o bloquearlo. Bloquear JavaScript, volver a cargar la página y comparar el sitio con y sin JavaScript debería mostrarle si falta algún elemento en la página o no. Si falta algo, vuelva a habilitar JavaScript y siga el mismo proceso de bloqueo que realizamos con CSS arriba para descubrir qué archivos son críticos para el contenido renderizado.

Mover al pie de página

Para los guiones en línea, puede considerar moverlos al pie de página. Recuerde que JavaScript está bloqueando el analizador, lo que significa que está bloqueando la lectura del HTML . Mover estos scripts al pie de página garantiza que gran parte de los datos se puedan procesar antes de que ocurra cualquier bloqueo. Tiene otras opciones para referencias de script que probablemente sean mejores, como diferir y async.

Diferir / asíncrono

Defer y Async son atributos que se pueden agregar a una etiqueta de script. Por lo general, un script que se descarga bloquea el analizador mientras se descarga y ejecuta. Async permitirá que el análisis y la descarga ocurran al mismo tiempo, pero aún se bloquea durante la ejecución del script. Aplazar no bloquea el análisis durante la descarga y solo se ejecuta después de que el HTML haya finalizado el análisis.
imagen pegada 0 60
Fuente: https://www.growingwiththeweb.com/2014/02/async-vs-defer-attributes.html .
Muestras de código diferido / asíncrono
Normal:
<script src="https://www.domain.com/file.js"></script>
Asíncrono:
<script src="https://www.domain.com/file.js" async></script>
Aplazar:
<script src="https://www.domain.com/file.js" defer></script>
Addy Osmani tiene un buen desglose de bloqueo, asíncrono, aplazamiento y precarga y cómo afecta las prioridades del navegador.
Addy Osmani @addyosmani
JavaScript loading priorities in Chrome: http://bit.ly/loading-priorities … ~ how do <script>, <script defer>, <link rel=preload> + <script async> & friends load then execute? A handy table.
View image on Twitter
2,570
2:30 AM - Feb 20, 2019
Twitter Ads info and privacy
966 people are talking about this

Sensibilidad

La capacidad de respuesta generalmente se mide por el primer retraso de entrada ( FID ), que es el tiempo desde que un usuario interactúa con su página hasta que puede responder. Max Potencial FID es el peor de los casos FID sus usuarios pueden experimentar. Muchas personas suelen medir el tiempo para interactuar ( TTI ), que es el tiempo que tarda una página en ser completamente interactiva.
¿Recuerdas las cosas que mencionamos anteriormente que estaban sucediendo en el hilo principal? Bueno, solo hay un hilo principal, y JavaScript compite por esos recursos. Mientras el hilo está bloqueado, no puede responder a la entrada del usuario, por lo que la página se siente lenta. Cuando un usuario hace clic y la página no realiza las acciones que solicitó de inmediato, siente ese retraso. Cuando esto sucede, sus usuarios pueden informarle y no de una manera agradable.
imagen pegada 0 66
Los usuarios se quejan de la lentitud de la aplicación de Twitter ... en Twitter.
Lo que impacta la capacidad de respuesta es JavaScript. Todo el JavaScript cargado para todas las cosas diferentes que puede lograr tiene que ejecutarse en el mismo lugar.
imagen pegada 0 64
La imagen de arriba es el aspecto del hilo principal. Esas marcas rojas en la pestaña Rendimiento en Chrome Dev Tools indican dónde puede haber algunos problemas. Por lo general, las tareas que toman demasiado tiempo para ejecutarse en el hilo principal son las marcadas. Cada uno de ellos es donde la página está sobrecargada de trabajo y no puede responder a la entrada del usuario de inmediato.
imagen pegada 0 62
Fuente: https://web.dev/long-tasks-devtools
Mientras se ejecuta una tarea, una página no puede responder a la entrada del usuario. Este es el retraso que se siente. Cuanto más larga sea la tarea, mayor será el retraso experimentado por el usuario. Los descansos entre tareas son las oportunidades que la página tiene para cambiar a la tarea de entrada del usuario y responder a lo que desea.

Etiquetas de terceros

Este es otro informe que puede encontrar en PageSpeed ​​Insights. Muestra el tamaño y cuánto tiempo los scripts de terceros bloquearon el hilo principal e impactaron la interactividad.
imagen pegada 0 67
Tenga en cuenta que, especialmente con los administradores de etiquetas, algunas cosas pueden contar para el administrador de etiquetas y no para el script que es el problema. Puede ser parte de la secuencia de comandos en el contenedor que cuenta para un administrador de etiquetas y no se cuenta correctamente para la secuencia de comandos de terceros.
Use el tamaño y el tiempo del hilo principal para determinar de qué puede deshacerse. Recuerde que la mayoría de los scripts de terceros agregan algún tipo de funcionalidad, seguimiento u orientación, pero rara vez son necesarios para que una página funcione correctamente. Use su criterio para determinar si los datos obtenidos valen el tiempo de carga adicional para estos scripts.

Fuentes comunes de JavaScript Bloat:

  • Jquery
  • Sistemas de prueba A / B
  • Sistemas de mapas de calor
  • Sistemas de monitoreo de usuario real ( RUM )
  • Sistemas de chat en vivo

Opciones de limpieza:

  1. Use menos seguimiento / scripts.  Esto puede ser una decisión difícil ya que los especialistas en marketing prefieren los datos, pero a veces la cantidad de datos recopilados es simplemente absurda.
  2. Consolide sistemas con una funcionalidad similar , como si ejecuta múltiples sistemas analíticos o múltiples sistemas que tienen información de usuario. Muchos programas tienen múltiples funciones, y a veces terminas con scripts que tienen la misma funcionalidad o una funcionalidad similar a otro script cuando quizás puedas prescindir de uno de ellos.
  3. La segmentación . Por ejemplo, algunos sistemas de prueba A / B almacenarán y lo obligarán a cargar una lista de todas las pruebas actualmente en el sistema, aumentando el tamaño de la descarga. Muchas veces puede segmentar por sección del sitio y crear versiones más pequeñas del archivo.
  4. Seguimiento del lado del servidor en lugar del lado del cliente.  Hay compensaciones con el seguimiento de esta manera que no cubriré aquí, pero puede encontrar muchos recursos sobre por qué podría usar uno sobre el otro.
  5. Utilice los trabajadores web para mover el procesamiento fuera del hilo principal.  La desventaja de hacer esto es que el trabajador web no tendrá acceso al DOM . Esto también es bastante avanzado y requiere desarrolladores expertos.
  6. Trabajadores de servicios / trabajadores de borde.  Estoy emocionado por lo que depara el futuro con esta tecnología. Básicamente, permite que JS se ejecute en Edge (o nivel CDN ) en lugar de en el navegador del cliente. Entonces, antes de un sistema de prueba A / B, puede ser que un archivo se descargue y luego se procese y ejecute en el navegador del cliente. Debido a que la prueba puede sobrescribir partes del DOM y suceder más tarde en la carga, es posible que vea destellos visuales a medida que cambian las cosas. Ahora, básicamente podría preprocesar los cambios que se realizarían y entregarlos en línea con el HTML que se entrega a los bots y usuarios. Algunas plataformas ya se están aprovechando de esto .
  7. Simplemente retrase la ejecución de la carga de un archivo  si no se necesita de inmediato o solo inicie la solicitud del archivo en función de una acción como un clic. Por ejemplo, un sistema de chat en vivo probablemente no sea necesario en los primeros cinco segundos de la carga de la página, así que retrasarlo. También puede solicitar el archivo después de que alguien se mueva o haga clic en un botón para que no se cargue con la página inicial. O use una imagen con un botón de reproducción en lugar de incrustar un video de YouTube y solo cargue en los elementos de video de YouTube y reproduzca el contenido cuando un usuario haga clic.

Beneficios de JS Frameworks:

Los marcos de JavaScript como React, Angular y Vue tienen algunos beneficios sobre los sistemas tradicionales.
  • Sacudida de árbol : entrega solo el código utilizado en la página. Los archivos o códigos adicionales no necesarios no se cargan, por lo que resulta en archivos más pequeños y páginas más pequeñas. Elimina el código tradicionalmente requerido para cualquier otra página y posibilidad.
  • División de código : división de archivos en fragmentos más pequeños, por lo que hay más oportunidades para la interactividad. Por ejemplo, supongamos que tiene un archivo JS de 1 MB que se ejecuta como una tarea larga en el hilo principal y bloquea la interactividad mientras se ejecuta. Puede dividirlo en fragmentos de 50 KB para que las tareas no se ejecuten tanto tiempo, y hay más espacios intermedios en períodos más cortos en los que una página podría responder a la entrada del usuario.

Fuentes de tipo de archivo

Con las fuentes, tiene muchas de las mismas opciones que mencionamos anteriormente (por ejemplo, incluir o precargar una fuente necesaria). Encontrará algunos ejemplos de código para precargar fuentes aquí  si desea seguir esa ruta. Sin embargo, con las fuentes, lo que recomendaría es usar font-display: swap ;, que simplemente usa una fuente predeterminada del sistema hasta que la fuente personalizada esté lista y luego intercambie la fuente personalizada. Esto es relativamente fácil de hacer en su hoja de estilo.
@Perfil delantero {
  font-family: 'Lo que sea';
  font-display: swap; 
}
Si está utilizando las fuentes de Google, es aún más fácil. Todo lo que necesita hacer es agregar &display=swap como parámetro en la URL .
<link href="https://fonts.googleapis.com/css?family=Whatever&display=swap" rel="stylesheet">

Imágenes de tipo de archivo

La principal preocupación con las imágenes es su tamaño y peso. Desea imágenes optimizadas que carguen el tamaño correcto para el dispositivo correcto y con la calidad correcta.
Las imágenes se cargan de forma asincrónica, por lo que no bloquean la carga de la página, pero pueden aumentar el peso y el tiempo total para interactuar.
Otro problema potencial tiene que ver con la priorización, donde algunas imágenes pueden no ser priorizadas correctamente o priorizadas antes de archivos críticos como CSS y JS . No entraré en detalles sobre esto, pero puede encontrar más detalles y alguna información sobre cómo solucionar problemas aquí  y aquí . También puede haber condiciones en las que se cargan muchas imágenes, maximizando los recursos como el ancho de banda y ralentizando la carga general de la página.
Muchas de las cosas de las que hemos hablado, como en línea y precarga, pueden usarse para imágenes pero con las mismas compensaciones como el almacenamiento en caché o la complejidad. La regla número uno es no utilizar muchas imágenes o imágenes grandes sobre el pliegue en su tema. No tiene que mostrar sus imágenes de fondo gigantes en dispositivos móviles. La gente puede vivir sin ellos. Si debe mostrar las imágenes, lo que recomendaría es precargar, y esta guía lo cubre bastante a fondo .
Hay una gran guía que cubre la optimización de imágenes y diferentes formatos en https://images.guide/ .
 
Siempre optimice la imagen de forma escalable. Hay muchas opciones para hacer esto en diferentes niveles, como con el CDN , el servidor, el CMS , una API , etc. Estas son algunas opciones:
CDN de optimización de imagen:
Akamai Image Manager  
imgix
Image Engine
Cloudinary
Uploadcare
API de optimización de imagen:
ShortPixel
Fastly Image Optimizer
Kraken.io
TinyPNG  
Imagify 
GUI :
ImageOptim  
Squoosh 
Línea de comando:
Imagemin  también tiene un  módulo npm si está usando webpack, gulp o gruñido
JPEG :
Guetzli  
MozJPEG
PNG :
pngquant  
Zopfli
GIF :
Gifsicle
SVGO 
WordPress / Drupal
No tengo ninguna recomendación en particular. Encontrarás muchas opciones para WordPress  y Drupal .

Imágenes de carga perezosa

Si alguien le dice que necesita "diferir las imágenes fuera de pantalla", esto es lo que necesita. Básicamente está retrasando la carga de imágenes que no están por encima del pliegue porque aún no son necesarias. Una vez que un usuario comienza a desplazarse, las imágenes se cargarán.
Diría que desea una biblioteca que use IntersectionObserver pero que probablemente tenga un polyfill debido a la compatibilidad con el navegador. La biblioteca más popular para esto es lazysizes , pero encontrarás muchas opciones para tu configuración.
A partir de Chrome 76, la carga diferida se ha introducido en el navegador. Espero que más navegadores hagan lo mismo pronto, pero por ahora, es posible que queramos usar este método para Chrome con un polyfill para otros navegadores. Puedes encontrar más información aquí . WordPress agregó carga diferida por defecto en la versión 5.4 .

Imágenes sensibles / redimensionadas

Se trata de servir la imagen correcta para la pantalla correcta. Cargar una imagen grande y luego reducirla solo desperdicia tiempo y recursos. De nuevo hay muchas soluciones automatizadas para esto. Por ejemplo, muchos CDN lo manejarán, y también hay cosas como el paquete npm nítido , la herramienta CLI ImageMagick o varios complementos / módulos para diferentes sistemas.

Cambio de formatos de imagen

Diferentes formatos como webp pueden ser mejores, pero son problemáticos debido al soporte del navegador. Tienes que hacer una gran cantidad de detección e intercambio o utilizar un servicio que lo haga por ti. Hay muchas guías , pero no es algo que recomendaría a la mayoría de las personas que aborden a menos que pueda encontrar una manera fácil y automatizada.

Tamaño de página / peso

Este es el tamaño de todos los recursos combinados. Las páginas más pequeñas son más rápidas. Ya hemos hablado de muchas de las mejoras como la minificación, la compresión y simplemente deshacerse de todo lo que no se usa. Cuanto menos tenga que cargar una página inicialmente, más rápido se mostrará la página.
El objetivo debe ser una cantidad mínima de datos para cargar el contenido por encima del pliegue lo más rápido posible. Luego puede cargar el resto de la información necesaria en la página después, todo mientras mantiene todo lo más pequeño posible. Los problemas generalmente provienen del código no utilizado, las imágenes y la hinchazón general del sitio web relacionada con la funcionalidad o las herramientas. La razón por la que le doy a esta su propia sección es que debe ser considerado con la cantidad total de datos que usa su página.
Consulte Cuánto cuesta mi sitio  para ver el costo aproximado para los usuarios que cargan su página.

Otras oportunidades de rendimiento web

Hay muchas opciones de cosas que puede hacer para mejorar la velocidad de su página. Voy a cubrir algunos más importantes, pero hay muchas más oportunidades porque la velocidad de la página es un tema tan complejo.

Almacenamiento en caché

Un caché es simplemente una copia almacenada de un archivo. Los archivos en caché se pueden reutilizar en la página siguiente sin tener que descargarlos nuevamente.
Caché del servidor
De aquí provienen los archivos cuando un navegador los solicita. Idealmente, desea alcanzar el caché más cercano al usuario. Lo que quiero decir con eso es que los cachés se pueden almacenar en muchos niveles diferentes con diferentes TTL establecidos para cada uno que hacen que caduque el caché. Existe un equilibrio entre el almacenamiento en caché durante períodos más largos y que el contenido se actualice rápidamente con los cambios. No es tan sencillo, ya que puede borrar el caché a través de diferentes capas cuando se realiza una actualización, que es la forma ideal de hacerlo junto con un sistema de calentamiento de caché. Los sistemas de calentamiento de caché envían un bot para reconstruir el caché en lugar de esperar a que un usuario solicite los archivos, lo que significa que un usuario nunca tiene que esperar mientras se construye el caché inicial.
Una comprobación suele ser algo así como: caché CDN > caché del servidor (como Varnish)> Origen (tiene que construir la página sobre la marcha). En general, un caché de nivel superior como el CDN será más rápido, por lo que desea que la mayoría de sus éxitos estén en ese nivel.
Por ejemplo, en uno de mis sitios en Cloudflare que se muestra a continuación, tengo un poco más del 50% de tasa de aciertos de caché para el nivel de CDN . Desafortunadamente, eso significa que muchas solicitudes no son atendidas por el CDN y tienen que volver al caché a nivel del servidor. O, si no hay una versión actual en caché allí, tendrá que construir la página sobre la marcha, que utiliza muchos recursos de la base de datos y será más lenta para un usuario.
imagen pegada 0 63
Caché de navegador
Incluso si tiene un sitio web grande que prueba mal la velocidad de la página, puede haber una diferencia considerable entre la primera y la segunda carga de una página o la navegación entre páginas. Mucho de lo que hemos hablado hasta ahora se centró en acelerar la carga inicial. Esto es lo que la mayoría de las herramientas de prueba ven y es la primera impresión de un usuario de su sitio web. Cuando un usuario visita una página, un navegador puede almacenar en caché muchos de los archivos localmente en la computadora de la persona, que se pueden reutilizar para las vistas posteriores de la página.
Por ejemplo, observe la diferencia entre la primera y la segunda carga para Ahrefs. La mayoría de los archivos que tuvieron que descargarse en la primera carga se almacenan en caché en el lado del cliente (navegador), lo que significa que la segunda carga puede reutilizar los que ya se descargaron para construir la página. Cortar el tiempo de conexión y las descargas significa que la página se carga significativamente más rápido. En este caso, First Paint ocurre aproximadamente el doble de rápido en la segunda carga.
1ra carga:
waterfall.php 7
2da carga:
waterfall.php 6
Verá problemas de almacenamiento en caché marcados en herramientas como Lighthouse como "servir activos estáticos con una política de caché eficiente". Establecer el período de tiempo para el caché varía según el sistema, pero en general, lo que debe hacer es usar un encabezado de respuesta HTTP de control de caché La edad máxima es el tiempo que desea almacenar en segundos y se puede configurar como:Cache-Control: max-age=31536000
Varvy tiene una guía para configurar controles de caché en diferentes servidores  que vale la pena leer.

Establecer un presupuesto de rendimiento (tal vez)

Un presupuesto de rendimiento es un conjunto de límites autoimpuestos en las métricas que afectan el rendimiento. Pueden ser cosas como el tamaño, el número de un determinado tipo de archivo o algunas de las métricas de velocidad de las que hemos hablado. Establecer un presupuesto puede ayudar a iniciar la conversación. Obtenga más información aquí .

Carga adaptativa

La carga adaptativa ajusta lo que se carga y cuándo hacer que los sitios sean más progresivos en cuanto a cómo se cargan. Las características y funcionalidades prioritarias se cargan primero, y el resto se cargan más tarde en función de cosas como la CPU , la memoria o la velocidad de la red. Por lo tanto, tener menos recursos disponibles significa que se puede entregar una versión simplificada del sitio, pero las personas con más recursos disponibles obtendrán toda la experiencia.
Una parte de esto es la API de información de red , que le brinda información sobre la conexión del usuario. Puede cambiar sus imágenes / contenido o hacer cosas como apagar videos en función de la información de red de la solicitud entrante. Muchos de los CDN de imágenes hacen esto utilizando la API de información de red .

Utilice otras sugerencias de recursos

Captación previa
Prefetch es una sugerencia de recursos que obtiene un archivo antes de que sea necesario. Esto puede ser para páginas enteras, scripts o archivos CSS . Una de las mejores formas de usar esto es con Guess.js , que utiliza la captación previa predictiva. Guess se conecta a su Analytics y obtiene la siguiente página más probable según el comportamiento actual del usuario.
Precarga
Ya hemos hablado un poco sobre la precarga, pero este es un caso de uso ligeramente diferente. Puede precargar recursos en función de cosas como un usuario que pasa el mouse sobre un enlace  o enlaces dentro de la ventana gráfica actual. Si bien esto puede ser un poco intensivo en recursos, asegura que la próxima página cargada aparecerá mucho más rápido.

AMPERIO

AMP precarga en el SERP , por lo que parte del sitio ya está cargado antes de hacer clic. AMP tiene la ventaja de tener la carga visual de la página antes de hacer clic. AMP se ve más rápido que las páginas web normales cuando proviene de los resultados de búsqueda porque la parte visible de la página ya está cargada.
imagen pegada 0 68
Fuente: https://www.ampproject.org/latest/blog/why-amp-caches-exist/
Hay muchas otras mejoras de rendimiento y limitaciones de tamaño de archivo dentro de AMP que hacen que valga la pena considerarlo. Aún así, es otro sistema para mantener y tiene otras compensaciones que probablemente desee considerar antes de sumergirse.

Datos de laboratorio versus datos de campo

Datos de laboratorio : las características son un entorno controlado, un proceso repetible y el control de la configuración. PageSpeed ​​Insights es un gran ejemplo. La prueba se ejecuta en el mismo entorno con la misma configuración, y los resultados serán aproximadamente los mismos con cada ejecución.
Datos de campo : Real User Monitoring ( RUM ) es la forma en que los usuarios experimentan la página. Tiene en cuenta todo, como el almacenamiento en caché, dispositivos, redes, etc., pero está limitado en métricas y la capacidad de depuración.
NOTA AL MARGEN.
 Tenga cuidado con el tiempo que usa las herramientas de Monitoreo de usuario real ( RUM ) que le permiten recopilar datos de campo. Si bien estas herramientas son excelentes para ver cómo se cargan las páginas para los usuarios, también pueden aumentar los tiempos de carga. Su objetivo es hacer que su sitio sea más rápido, y esto puede ser útil para diagnosticar problemas, pero dejarlos activados puede hacer que sus páginas se carguen más lentamente.

Herramientas para medir la velocidad de la página

Herramientas de Google

  • TestMySite  : contiene un cuadro de mandos de velocidad en el que puede evaluar su velocidad frente a los competidores, tiene una calculadora de impacto para que pueda estimar el impacto que la velocidad está teniendo en su negocio y le permite crear un informe que incluye estas y algunas recomendaciones sobre cosas en las que enfocarse en.
  • Lighthouse  (en Chrome Dev Tools): permite probar el rendimiento de páginas y aplicaciones.
  • PageSpeed ​​Insights  : ejecuta Lighthouse  y proporciona recomendaciones. La ejecución de Lighthouse en su navegador se ve afectada por muchas cosas como su computadora, su red, las extensiones en su navegador, etc. PageSpeed ​​Insights permite un entorno de prueba bastante estable que ni siquiera utiliza los recursos de su servidor como lo haría un Lighthouse en la configuración a escala .
  • Chrome Dev Tools  : muchas funciones útiles para ver qué y cómo se carga una página, como las pestañas Red y Rendimiento.
  • Informe de experiencia de usuario de Chrome (CrUX)  : un conjunto de datos públicos de datos de experiencia de usuario real para aquellos que optaron por compartir en Chrome que cubre millones de sitios web. Datos de campo (datos de usuarios reales) para la velocidad de la página.
  • Web.dev  : otra herramienta de prueba de Google respaldada por Lighthouse. También tiene una sección para aprender más sobre la velocidad de la página.

Otras herramientas de velocidad populares

  • WebPageTest
  • Sitespeed.io
  • SpeedCurve
  • Calibre
  • Rigor
  • Nueva reliquia
  • Bumerang
  • Velocidad de lote
  • GTmetrix
  • Pingdom
  • SpeedMonitor.io

Auditoría del sitio> Rendimiento

La herramienta de Auditoría del Sitio de Ahrefs también  contiene información sobre la velocidad de la página. Hay un informe para TTFB y para Tiempo de carga, que es el tiempo que nos llevó descargar la página.
9 ahrefs auditoría del sitio 3
Lo que personalmente tiendo a usar:
  1. Pagespeed Insights  : comprobación individual de páginas. También me gusta su API . Permite 25k pruebas por día sin costo y regresa con muchas métricas, incluidos datos de nivel de página CrUX. Diré que no presto mucha atención al puntaje general, pero sé que mucha gente se enfoca en esta métrica. Como hemos visto, la velocidad es compleja y es posible que esté mejorando algunas métricas sin ayudar a su puntaje solo por la forma en que está ponderado .
  2. WebPageTest  : la función de bloqueo, tiras de película, video, cascada y mapa de solicitudes. Además, su API para bloquear pruebas a escala (con informes de faros también).
  3. GTmetrix  : el informe de solicitudes encadenadas.
  4. CrUX  : investigación regional, histogramas, comparación de competidores.
  5. Web.dev  : la documentación es excelente.

¿Qué datos usa Google para la velocidad de la página?

Según el analista de tendencias de Google Webmaster John Mueller en este video , Google usa la velocidad teórica de una página (usando datos de laboratorio) y datos de campo reales de los usuarios que han intentado usar esas páginas. Él dice que esto es similar a los datos en el Informe de experiencia de usuario de Chrome.
La realidad es que no ha habido ninguna confirmación pública de la fuente de los datos que utilizan. Si bien John no dice que usan datos de PageSpeed ​​Insights y CrUX, es probable que los datos de estos sean representativos de los datos que utiliza Google. Mi mejor suposición (y esto es puramente especulativo) es que usan medidas tomadas durante su proceso de renderizado como datos de laboratorio (potencialmente por faro, pero tal vez no), y es probable que tengan un recurso interno similar a CrUX que están usando para el campo datos.

La forma más fácil de estimar el impacto es hacer una copia estática de una página. Copie el código en su servidor y pruebe la página para obtener una métrica de referencia. Realice cambios en la página y pruebe nuevamente, y debería obtener el impacto aproximado de los cambios, de modo que cuando los realice en su sitio en vivo, sepa el impacto aproximado.

No hay comentarios.:

Publicar un comentario

Dejanos tu comentario para seguir mejorando!

outbrain

Páginas