Minimice la subparte de Duración de DNS del Time to First Byte

Minimice la subparte de Duración de DNS del Time to First Byte

Este artículo es parte de nuestra guía de Time to First Byte (TTFB). La duración de DNS es la tercera subparte del TTFB y representa el tiempo que el navegador pasa resolviendo su nombre de dominio en una dirección IP. Para los visitantes por primera vez que no tienen un registro DNS en caché, la búsqueda DNS puede añadir de 20 a 200 milisegundos al TTFB dependiendo del proveedor de DNS, la ubicación geográfica del usuario y la configuración TTL de sus registros DNS.

El Time to First Byte (TTFB) se puede desglosar en las siguientes subpartes:

• Espera + Redirección (o duración de espera)
• Worker + Caché (o duración de caché)
• DNS (o duración de DNS)
• Conexión (o duración de conexión)
• Solicitud (o duración de solicitud)

¿Busca optimizar el Time to First Byte? Este artículo proporciona un análisis en profundidad de la parte de duración de DNS del Time to First Byte. Si busca entender o arreglar el Time to First Byte y no sabe qué significa la duración de DNS, por favor lea qué es el Time to First Byte y arreglar e identificar problemas de Time to First Byte antes de comenzar con este artículo.

Solución rápida de DNS: si experimenta latencia de DNS en el Time to First Byte, ¡cambie a un proveedor de DNS premium y actualice su configuración TTL!

La parte de Duración de DNS del Time to First Byte consiste en el tiempo en que el navegador busca la dirección de internet (IP) de su sitio. Necesitamos búsquedas DNS porque a nosotros los humanos nos resulta más fácil recordar nombres de dominio como "www.example.com" mientras que las computadoras requieren direcciones IP numéricas para conectarse entre sí.

¿Cómo funciona el DNS?

Las solicitudes DNS se incluyen en la medición del TTFB. Esto significa que el tiempo que tarda en finalizar la solicitud DNS se tiene en cuenta en la puntuación general del TTFB.

Cuando se solicita una página, estos son los pasos que toma su navegador para convertir el nombre de dominio en una dirección IP:

• Se verifica la caché DNS del navegador: Antes de realizar una consulta DNS, el navegador primero verifica su propia caché DNS para ver si ya tiene la dirección IP del dominio solicitado. Los navegadores modernos almacenan en caché los registros DNS durante un período establecido para mejorar el rendimiento reduciendo la necesidad de búsquedas DNS repetidas. Si el registro se encuentra en la caché del navegador, el navegador puede usarlo inmediatamente sin más consultas.
• Se verifica la caché del sistema operativo: Si la caché del navegador no contiene el registro DNS necesario, la solicitud se pasa al resolutor DNS del sistema operativo, a menudo llamado "stub resolver". El SO también mantiene una caché DNS y la verificará antes de enviar cualquier solicitud de red.
• Consulta DNS: Si el registro DNS no se encuentra ni en la caché del navegador ni en la del SO, se envía una consulta DNS recursiva a un resolutor DNS, típicamente proporcionado por el Proveedor de Servicios de Internet (ISP) del usuario. Este resolutor actúa como un intermediario, manejando el proceso de consultar otros servidores DNS para encontrar la dirección IP.
  • Servidores de Nombres Raíz: El resolutor primero contacta un servidor de nombres raíz, que lo dirige al servidor de dominio de nivel superior (TLD) apropiado basado en la extensión del dominio (p. ej., ".com", ".org").
  • Servidores de Nombres TLD: El servidor TLD luego dirige al resolutor al servidor de nombres autoritativo para el dominio específico.
  • Servidor de Nombres Autoritativo: Este servidor contiene los registros DNS para el dominio y proporciona al resolutor la dirección IP.
• Devolver la dirección IP: Una vez que el resolutor DNS obtiene la dirección IP del servidor autoritativo, devuelve esta información al navegador. El navegador puede entonces iniciar una conexión con el servidor usando la dirección IP para cargar la página web solicitada.

¿Cómo afecta el DNS al Time to First Byte?

Para visitantes recurrentes, la búsqueda DNS generalmente se almacena en caché en el navegador o SO, reduciendo la duración de DNS a casi cero. Para visitantes por primera vez, sin embargo, la búsqueda DNS recursiva completa debe completarse antes de que el navegador pueda proceder al paso de conexión TCP. Es por esto que el TTFB es a menudo mediblemente peor para nuevos visitantes en comparación con los recurrentes.

Use dns-prefetch y preconnect para dominios de terceros

Si su página carga recursos de dominios de terceros (como análisis, fuentes o subdominios CDN), el navegador debe resolver el DNS para cada dominio por separado. Puede indicar al navegador que inicie la resolución DNS temprano utilizando la sugerencia de recurso dns-prefetch:

<!-- DNS prefetch for third-party domains -->
<link rel="dns-prefetch" href="https://fonts.googleapis.com">
<link rel="dns-prefetch" href="https://cdn.example.com">
<link rel="dns-prefetch" href="https://analytics.example.com">

Para orígenes de terceros críticos donde sabe que también necesitará establecer una conexión TCP y TLS, use preconnect en su lugar, que incluye la resolución DNS más el handshake de conexión:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Use dns-prefetch como respaldo para navegadores que no soportan preconnect:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="dns-prefetch" href="https://fonts.googleapis.com">

Coloque estas sugerencias en el <head> de su HTML lo antes posible. Solo agregue sugerencias para dominios que su página realmente usa; agregar sugerencias para dominios no utilizados desperdicia recursos del navegador. Para más técnicas de optimización relacionadas con la carga de recursos, vea nuestra guía sobre 103 Early Hints.

Cómo minimizar el impacto de DNS en el TTFB

Use un proveedor de DNS rápido

Algunos proveedores de DNS son más rápidos que otros. Elegir un proveedor de DNS rápido y confiable es una de las formas más fáciles de reducir la latencia de DNS. Los proveedores de DNS premium como Cloudflare, Amazon Route 53 y Google Cloud DNS tienen infraestructuras globales extensas. Esas infraestructuras reducen la distancia física entre los usuarios y los servidores DNS, eliminando una parte importante de la latencia involucrada en las solicitudes DNS.

Aquí hay una comparación de proveedores de DNS populares y sus tiempos de respuesta típicos:

La diferencia entre un proveedor de DNS premium y un DNS de registrador básico puede ser de 40 a 90 milisegundos por búsqueda. Para visitantes por primera vez, esto se traduce directamente en un TTFB más rápido. Para aprender cómo configurar Cloudflare como su proveedor de DNS y CDN, lea nuestra guía para configurar Cloudflare.

Optimice el Time to Live de la caché DNS

El almacenamiento en caché de DNS guarda los resultados de las consultas DNS localmente, reduciendo la necesidad de búsquedas repetidas. Al establecer valores "óptimos" de Time-To-Live (TTL) para los registros DNS, puede controlar cuánto tiempo se almacenan en caché estos registros.

Valores TTL más bajos significan que los registros caducan antes, causando búsquedas DNS más frecuentes. Valores TTL más altos significan que los registros se almacenan en caché por más tiempo, reduciendo las búsquedas DNS pero haciendo que los cambios de DNS se propaguen más lento. El TTL correcto depende de con qué frecuencia cambie sus registros DNS y cuánto valore la velocidad de búsqueda DNS frente a la flexibilidad.

¿Cuáles son las configuraciones óptimas de TTL de DNS?

Al planificar una migración de DNS o cambio de servidor, reduzca temporalmente su TTL a 5 minutos (300 segundos) al menos 24 horas antes de realizar el cambio. Esto asegura que después del cambio, los usuarios recogerán la nueva dirección IP rápidamente. Una vez completada y verificada la migración, aumente el TTL de nuevo a un valor más alto para reducir la frecuencia de búsqueda DNS.

CONSEJO: si está utilizando registros CNAME, considere implementar CNAME flattening. CNAME flattening es una técnica que le permite usar un registro CNAME en el nivel de dominio raíz (apex), resolviéndolo efectivamente en una dirección IP sin violar los estándares DNS. Esto elimina una búsqueda DNS extra que de otro modo sería necesaria para resolver el CNAME a su objetivo, luego el objetivo a su dirección IP.

DNS over HTTPS (DoH) y DNS over TLS (DoT)

Las consultas DNS tradicionales se envían en texto plano sobre UDP, lo que significa que pueden ser interceptadas, modificadas o bloqueadas por intermediarios (como ISPs u operadores de red). DNS over HTTPS (DoH) y DNS over TLS (DoT) cifran las consultas DNS, mejorando tanto la privacidad como la seguridad.

Aunque DoH y DoT abordan principalmente preocupaciones de seguridad y privacidad, también pueden afectar el rendimiento de la resolución DNS:

• Impacto de latencia: la sobrecarga de cifrado añade una pequeña cantidad de latencia a la conexión DNS inicial (handshake TLS). Sin embargo, debido a que las conexiones DoH/DoT son persistentes y reutilizadas, las consultas subsiguientes en la misma conexión suelen ser más rápidas que el DNS tradicional.
• Interferencia del ISP: algunos ISPs inyectan sus propias respuestas DNS o ralentizan las consultas DNS para no clientes. DoH evita esta interferencia por completo, lo que puede mejorar el tiempo de resolución DNS para los usuarios afectados.
• Soporte del navegador: los navegadores modernos (Chrome, Firefox, Edge, Safari) soportan DoH. En la mayoría de los casos, el proveedor de DNS predeterminado del navegador ya usa DoH cuando está disponible.

Para los propietarios de sitios web, no pueden controlar si sus visitantes usan DoH o DoT (eso es una configuración a nivel de navegador y SO). Sin embargo, puede asegurarse de que su proveedor de DNS autoritativo soporte DNSSEC, que proporciona una capa complementaria de verificación para las respuestas DNS independientemente del cifrado de transporte.

Medir la duración de DNS con JavaScript

Puede medir la subparte de duración de DNS del TTFB directamente en el navegador usando la API de Navigation Timing:

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');
  const dnsDuration = nav.domainLookupEnd - nav.domainLookupStart;

  console.log('DNS Duration:', dnsDuration.toFixed(0), 'ms');

  if (dnsDuration > 50) {
    console.warn('High DNS duration detected. Consider:');
    console.warn('1. Switching to a premium DNS provider');
    console.warn('2. Increasing DNS TTL values');
    console.warn('3. Using dns-prefetch for third-party domains');
  }
}).observe({
  type: 'navigation',
  buffered: true
});

Una duración de DNS de 0ms en sus datos RUM indica típicamente que la búsqueda DNS fue servida desde la caché del navegador o SO (un escenario de visitante recurrente). Valores por encima de 50ms sugieren que el usuario tuvo que realizar una búsqueda DNS recursiva completa, lo cual es común para visitantes por primera vez.

Cómo medir problemas de TTFB causados por búsquedas DNS lentas

Para encontrar el impacto que experimentan los usuarios reales causado por la latencia DNS, necesitará usar una herramienta RUM como CoreDash. Real User Monitoring le permitirá rastrear los Core Web Vitals con mayor detalle y sin el retraso de 28 días de Google.

En CoreDash, haga clic en "Desglose de Time to First Byte" para visualizar la parte de DNS del Time to First Byte.

Lectura adicional: Guías de optimización

Para técnicas de optimización relacionadas que complementan la optimización DNS, explore estas guías:

• 103 Early Hints: envíe sugerencias de recursos antes de que la respuesta completa esté lista, permitiendo al navegador iniciar la resolución DNS y las conexiones para recursos críticos incluso antes.
• Configurar Cloudflare para rendimiento: use Cloudflare como su proveedor de DNS y CDN, combinando una resolución DNS rápida con caché en el borde y soporte HTTP/3.

Subpartes del TTFB: Artículos detallados

La duración de DNS es una de las cinco subpartes del TTFB. Explore las otras subpartes para entender el panorama completo:

• Arreglar e identificar problemas de TTFB: el punto de partida de diagnóstico para toda optimización de TTFB.
• Duración de espera: redirecciones, cola del navegador y optimización HSTS.
• Duración de caché: rendimiento del service worker, búsquedas de caché del navegador y bfcache.
• Duración de conexión: handshake TCP, optimización TLS, HTTP/3 y preconnect.