El primer paso para crear un sitio web que se cargue rápido es recibir una
respuesta del servidor para el código HTML de una página. Cuando ingresas una URL
en la barra de direcciones del navegador, este envía una solicitud GET al servidor para
y recuperarlos. La primera solicitud de una página web es para un recurso HTML.
asegurarse de que el HTML llegue rápidamente con retrasos mínimos es una clave de
de tu objetivo.
Esa solicitud inicial de HTML pasa por varios pasos, cada uno de los cuales algún tiempo. Reducir el tiempo dedicado a cada paso te brinda un Tiempo de Primer byte (TTFB). Aunque el TTFB no es la única métrica en la que debes enfocarte cuando en cuanto a la velocidad de carga de las páginas, un TTFB alto sí dificulta el alcance el estado designado como “bueno” umbrales para métricas como el Procesamiento de imagen con contenido más grande (LCP) y el primer procesamiento de imagen con contenido (FCP).
Reducir redireccionamientos
Cuando se solicita un recurso, el servidor puede responder con un redireccionamiento, ya sea
con un redireccionamiento permanente (una respuesta 301 Moved Permanently) o una configuración
uno (una respuesta 302 Found).
Los redireccionamientos ralentizan la velocidad de carga de las páginas porque el navegador debe realizar una una solicitud HTTP adicional en la nueva ubicación para recuperar el recurso. Existen Hay dos tipos de redireccionamientos:
- Redireccionamientos del mismo origen que ocurren completamente dentro del origen. Estos tipos de redireccionamientos están completamente bajo tu control, ya que la lógica para administrar residen completamente en tu servidor web.
- Redireccionamientos de origen cruzado que inicia otro origen Estos tipos de redireccionamientos están fuera de tu control.
Los anuncios, los servicios de acortamiento de URL y otros servicios de terceros. Si bien los redireccionamientos de origen cruzado están fuera de su control, le recomendamos que se asegure de evitar los redireccionamientos múltiples, por ejemplo, tener un anuncio que se vincula a una página HTTP que, a su vez, redirecciona a las páginas HTTPS equivalente o un redireccionamiento de origen cruzado que llega a tu origen, pero luego activa un redireccionamiento del mismo origen.
Respuestas HTML en caché
Almacenar respuestas HTML en caché es difícil, ya que la respuesta puede incluir vínculos a otros recursos críticos como CSS, JavaScript, imágenes y otros recursos de tipos de datos. Estos recursos pueden incluir una huella digital única en sus respectivas nombres de archivo, que cambia según el contenido de un archivo. Esto significa que tu almacenamiento El documento HTML puede quedar inactivo después de una implementación, ya que tendría referencias a subrecursos desactualizados.
No obstante, una vida útil de caché breve, en lugar de la ausencia de almacenamiento en caché, puede tener ventajas como permitir que un recurso se almacene en caché en una CDN, lo que reduce la cantidad de que se entregan desde el servidor de origen, y en el navegador, lo que permite en lugar de volver a descargar los recursos. Este enfoque funciona la mejor opción para el contenido estático que no cambia en ningún contexto y una respuesta el tiempo de almacenamiento en caché de los recursos puede establecerse en algunos minutos que consideres lo que sea apropiado. Cinco minutos para los recursos HTML estáticos es una apuesta segura y garantiza para garantizar que las actualizaciones periódicas no pasen desapercibidas.
Si el contenido HTML de una página está personalizado de alguna manera (por ejemplo, para una usuario autenticado, es muy probable que no quieras almacenar en caché el contenido durante diversas inquietudes, incluida la seguridad y actualidad. Si una respuesta HTML es almacenada en caché por el navegador del usuario, no se puede invalidar la caché. Es por lo que es mejor evitar almacenar HTML en caché en esos casos.
Un enfoque cauteloso para almacenar HTML en caché podría ser usar ETag, o
Last-Modified encabezados de respuesta. Un ETag, también conocido como entidad
etiqueta: el encabezado es un identificador que representa de manera inequívoca al recurso solicitado,
A menudo, con un hash del contenido del recurso:
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
Cada vez que cambia el recurso, se debe generar un valor ETag nuevo. Activada
solicitudes posteriores, el navegador envía el valor ETag a través del
Encabezado de la solicitud If-None-Match. Si el ETag del servidor coincide con el
que envía el navegador, el servidor da una respuesta 304 Not Modified
y el navegador usa el recurso de la caché. Si bien esto genera
latencia de red, una respuesta 304 Not Modified es mucho más pequeña que una respuesta
recurso HTML.
Sin embargo, la latencia de red necesaria para la revalidación de la actualidad de un recurso es sigue siendo su propia desventaja. Al igual que con muchos otros aspectos del desarrollo web, las concesiones y los compromisos son inevitables. Depende de ti averiguar si los un esfuerzo adicional para almacenar en caché HTML de esta manera vale la pena, o si es mejor se mantengan seguros y no se molesten en almacenar contenido HTML en caché.
Mide los tiempos de respuesta del servidor
Si una respuesta no se almacena en caché, el tiempo de respuesta del servidor depende en gran medida de para tu proveedor de hosting y la pila de aplicaciones de backend. Una página web que publica una respuesta generada de forma dinámica, como recuperar datos de una base de datos, para ejemplo, quizás tenga un TTFB más alto que una página web estática que se puede publicar de forma inmediata sin tener un tiempo de procesamiento significativo en el backend. Se muestra un el ícono giratorio de carga y la recuperación de todos los datos del cliente mueve el esfuerzo de un entorno del servidor más predecible a una situación del cliente. Minimizar el esfuerzo del cliente suele dar como resultado una mejora métricas centradas en los usuarios.
Si los usuarios experimentan un TTFB lento en el campo, puede exponer la información
sobre dónde se pasó tiempo en el servidor mediante el uso de Server-Timing
encabezado de respuesta:
Server-Timing: auth;dur=55.5, db;dur=220
El valor de un encabezado Server-Timing puede incluir varias métricas, así como una
la duración de cada uno. Luego, estos datos se pueden recopilar de los usuarios en el campo
usando la API de Navigation Timing y se analizan para ver si los usuarios experimentan
las demoras. En el fragmento de código anterior, el encabezado de respuesta incluye dos tiempos:
- El tiempo para autenticar a un usuario (
auth), que demoró 55.5 milisegundos. - El tiempo de acceso a la base de datos (
db), que demoró 220 milisegundos
También puedes revisar tu infraestructura de hosting y confirmar que tener los recursos adecuados para manejar el tráfico que recibe tu sitio web. Compartida los proveedores de hosting suelen ser susceptibles de tener un TTFB alto, por lo que las soluciones dedicadas que proporcionan tiempos de respuesta más rápidos puede ser más costoso.
Compresión
Las respuestas basadas en texto, como las imágenes HTML, JavaScript, CSS y SVG, deben para reducir el tamaño de la transferencia en la red y poder descargar más rápido. Los algoritmos de compresión más utilizados son gzip y Brotli Brotli genera una mejora de entre un 15% y un 20% en comparación con gzip.
La mayoría de los proveedores de hosting web configuran automáticamente la compresión, debes considerar algunos aspectos importantes si estás en condiciones de configurar o modifica la configuración de compresión por tu cuenta:
- Usa Brotli siempre que sea posible. Como se mencionó anteriormente, Brotli ofrece un mejora notable en comparación con gzip, y Brotli es compatible con todas las navegadores. Usa Brotli siempre que sea posible, pero si una alta cantidad de usuarios cantidad de usuarios en navegadores heredados, asegúrate de usar gzip como resguardo, ya que cualquier compresión es mejor que no realizar ninguna compresión.
- El tamaño de los archivos es importante. Los recursos muy pequeños (menos de 1 KiB) no se comprimen. muy bien o, a veces, ni siquiera se comprimen. Eficacia de cualquier tipo de la compresión de datos depende de tener una gran cantidad de datos que un de compresión puede funcionar para encontrar más bits comprimibles de los datos. Cuanto más grande sea el archivo, mejor funcionará la compresión. Sin embargo, no debes y envían recursos muy grandes porque pueden comprimirse más con eficacia. Los recursos grandes, como JavaScript y CSS, toman mucho más tiempo para analizar y evaluar una vez que el navegador haya descomprimirlos y pueden cambiar con más frecuencia, incluso si solo se modifica de manera marginal, ya que los cambios generan un hash de archivo diferente.
- Comprende la compresión dinámica y estática. Dinámico y estático de compresión son enfoques diferentes con respecto a cuándo un recurso debe ser comprimidos. La compresión dinámica comprime un recurso en el momento en que se request y, en ocasiones, cada vez que se solicita. Por otro lado, La compresión estática comprime los archivos con anticipación y no requiere compresión. que se realizará al momento de la solicitud. La compresión estática quita La latencia involucrada en la compresión, que puede aumentar la respuesta del servidor en el caso de la compresión dinámica. Los recursos estáticos, como las imágenes de JavaScript, CSS y SVG, deben comprimirse de forma estática, mientras que los formatos HTML recursos, en especial si se generan de forma dinámica para los usuarios) deben comprimirse de forma dinámica.
Hacer la compresión adecuada por su cuenta es un desafío y, a menudo, es mejor dejar que una red de distribución de contenidos (CDN), que se analiza en la siguiente sección, para encargarse de esto por ti. Sin embargo, conocer estos conceptos puede ayudarte a discernir si tu proveedor de hosting está utilizando la compresión correctamente. Ese conocimiento puede te ayudan a encontrar oportunidades para mejorar tu configuración de compresión para que obtener el máximo beneficio para tu sitio web.
Redes de distribución de contenidos (CDN)
Una red de distribución de contenidos (CDN) es una red distribuida de servidores que almacenar en caché los recursos del servidor de origen y, a su vez, los entrega servidores que están físicamente más cerca de los usuarios. La proximidad física a tu reduce el tiempo de ida y vuelta (RTT), mientras que las optimizaciones como HTTP/2 o HTTP/3, el almacenamiento en caché y la compresión permiten que la CDN entregue contenido con mayor rapidez. que si se recuperara del servidor de origen. Usar una CDN puede mejorar significativamente el TTFB de tu sitio web en algunos casos.
Ponga a prueba sus conocimientos
¿Qué tipo de redireccionamiento tienes bajo tu control?
El encabezado Server-Timing puede contener varias métricas.
El tipo de servidor que tiene más probabilidades de estar físicamente más cerca de tu extremo usuarios?
A continuación: Comprende la ruta crítica
Ahora que conoces algunas de las consideraciones de rendimiento con el HTML de su sitio web, estará en una mejor posición para asegurarse de que pueda cargarse lo más rápido posible, pero eso es solo el comienzo rendimiento. A continuación, la teoría detrás de la ruta de acceso de renderización crítica es que se tratará. Este módulo describe conceptos clave, como el bloqueo de renderizado y recursos de bloqueo de análisis y el rol que cumplen en la obtención de la respuesta en el navegador lo más rápido posible.