Minimiza la subparte de duración de DNS del Time to First Byte.

Minimiza 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. Representa el tiempo que el navegador pasa resolviendo tu nombre de dominio a una dirección IP. Para los visitantes nuevos sin un registro DNS en caché, la búsqueda DNS añade entre 20 y 200 milisegundos al TTFB. Esto depende del proveedor de DNS, la ubicación del usuario y la configuración TTL de tus registros DNS.

El Time to First Byte (TTFB) se divide 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)
• Petición (o duración de petición)

¿Buscas optimizar el Time to First Byte? Este artículo cubre la duración de DNS del Time to First Byte. Si quieres entender o arreglar el Time to First Byte y no sabes qué significa la duración de DNS, lee primero qué es el Time to First Byte e identifica y corrige problemas del Time to First Byte.

Solución rápida de DNS: ¡Si tienes latencia de DNS en el Time to First Byte, cambia a un proveedor de DNS premium y actualiza tu configuración TTL!

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

¿Cómo funciona el DNS?

Las peticiones DNS se incluyen en la medición del TTFB. Esto significa que el tiempo que tarda la petición DNS en terminar se incluye en la puntuación general del TTFB.

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

• Se comprueba la caché DNS del navegador: Antes de hacer una consulta DNS, el navegador revisa primero su propia caché DNS. Busca si ya tiene la dirección IP del dominio solicitado. Los navegadores modernos almacenan en caché los registros DNS durante un tiempo para mejorar el rendimiento. Esto reduce la necesidad de búsquedas DNS repetidas. Si encuentra el registro en la caché del navegador, este lo usa inmediatamente sin más consultas.
• Se comprueba la caché del sistema operativo: Si la caché del navegador no tiene el registro DNS necesario, la petición pasa al resolvedor DNS del sistema operativo (a menudo llamado "stub resolver"). El SO también mantiene una caché DNS. La revisará antes de enviar cualquier petición de red.
• Consulta DNS: Si el registro DNS no está en la caché del navegador ni en la del SO, se envía una consulta DNS recursiva a un resolvedor DNS. Típicamente lo proporciona el proveedor de internet (ISP) del usuario. Este resolvedor actúa como intermediario. Gestiona el proceso de consultar a otros servidores DNS para encontrar la dirección IP.
  • Servidores de nombres raíz: El resolvedor primero contacta con un servidor de nombres raíz. Este lo dirige al servidor de dominio de nivel superior (TLD) adecuado según la extensión del dominio (por ejemplo, ".com", ".org").
  • Servidores de nombres TLD: El servidor TLD dirige al resolvedor al servidor de nombres autoritativo del dominio específico.
  • Servidor de nombres autoritativo: Este servidor contiene los registros DNS del dominio. Proporciona al resolvedor la dirección IP.
• Devuelve la dirección IP: Una vez que el resolvedor 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 impacta el DNS en el Time to First Byte?

Para los visitantes recurrentes, la búsqueda DNS suele estar en la caché del navegador o del SO. Esto reduce la duración de DNS a casi cero. Sin embargo, para los visitantes nuevos, la búsqueda DNS recursiva completa debe terminar antes de que el navegador pase al paso de conexión TCP. Por esto el TTFB suele ser considerablemente peor para los visitantes nuevos en comparación con los recurrentes.

Usa dns-prefetch y preconnect para dominios de terceros

Si tu página carga recursos de dominios de terceros (como analíticas, fuentes o subdominios CDN), el navegador debe resolver el DNS para cada dominio por separado. Puedes ordenar al navegador que inicie antes la resolución DNS usando el resource hint 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 sabes que también necesitarás establecer una conexión TCP y TLS, usa preconnect en su lugar. Esto 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>

Usa dns-prefetch como fallback para navegadores que no soportan preconnect:

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

Coloca estos hints en el <head> de tu HTML lo antes posible. Solo añade hints para dominios que tu página usa realmente. Añadir hints para dominios no utilizados desperdicia recursos del navegador. Para más técnicas de optimización sobre la carga de recursos, consulta nuestra guía sobre 103 Early Hints.

Cómo minimizar el impacto del DNS en el TTFB

Usa 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 fiable es una de las formas más fáciles de reducir la latencia de DNS. Proveedores premium como Cloudflare, Amazon Route 53 y Google Cloud DNS operan servidores en cientos de ubicaciones mundiales. Cuanto más cerca esté el servidor DNS de tu usuario, más rápida será la búsqueda.

Aquí tienes 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 básico de registrador puede ser de 40 a 90 milisegundos por búsqueda (fuente: benchmarks de DNSPerf). Para los visitantes nuevos, esto se traduce directamente en un TTFB más rápido. Para aprender a configurar Cloudflare como tu proveedor de DNS y CDN, lee nuestra guía para configurar Cloudflare.

Optimiza el Time to Live de la caché DNS

La caché DNS almacena localmente los resultados de las consultas DNS. Esto reduce la necesidad de búsquedas repetidas. Al establecer valores de Time-To-Live (TTL) "óptimos" para los registros DNS, controlas cuánto tiempo se cachean estos registros.

Los valores TTL bajos hacen que los registros caduquen antes. Esto causa búsquedas DNS más frecuentes. Los valores TTL altos mantienen los registros en caché más tiempo. Esto reduce las búsquedas DNS, pero hace que los cambios DNS se propaguen más lento. El TTL correcto depende de con qué frecuencia cambias tus registros DNS y de cuánto valoras la velocidad de búsqueda frente a la flexibilidad.

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

Al planificar una migración DNS o cambio de servidor, baja temporalmente tu TTL a 5 minutos (300 segundos) al menos 24 horas antes de hacer el cambio. Esto asegura que, tras el cambio, los usuarios adoptarán la nueva dirección IP rápidamente. Una vez completada y verificada la migración, sube el TTL de nuevo a un valor mayor para reducir la frecuencia de las búsquedas DNS.

CONSEJO: Si usas registros CNAME, considera implementar CNAME flattening. CNAME flattening es una técnica que te permite usar un registro CNAME en el nivel raíz del dominio (apex). Lo resuelve a 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, y 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. Esto 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. Esto mejora la privacidad y la seguridad.

Aunque DoH y DoT solucionan principalmente problemas de seguridad y privacidad, también pueden afectar al rendimiento de la resolución DNS:

• Impacto en la latencia: La carga del cifrado añade una pequeña latencia a la conexión DNS inicial (handshake TLS). Sin embargo, como las conexiones DoH/DoT son persistentes y se reutilizan, las siguientes consultas en la misma conexión suelen ser más rápidas que en el DNS tradicional.
• Interferencia del ISP: Algunos ISPs inyectan sus propias respuestas DNS o ralentizan las consultas DNS de los no clientes. DoH evita esta interferencia por completo. Esto 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 por defecto del navegador ya usa DoH cuando está disponible.

Como propietario del sitio web, no puedes controlar si tus visitantes usan DoH o DoT (es una configuración a nivel de navegador y SO). Sin embargo, puedes asegurarte de que tu proveedor de DNS autoritativo soporte DNSSEC. Esto proporciona una capa complementaria de verificación para las respuestas DNS sin importar el cifrado de transporte.

Medición de la duración de DNS con JavaScript

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

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 0 ms en tus datos de RUM suele indicar que la búsqueda DNS se sirvió de la caché del navegador o del SO (un escenario de visitante recurrente). Valores por encima de 50 ms sugieren que el usuario tuvo que hacer una búsqueda DNS recursiva completa. Esto es común en los visitantes nuevos.

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

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

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

Lecturas recomendadas: Guías de optimización

Guías relacionadas:

• 103 Early Hints: Envía resource hints antes de que la respuesta completa esté lista. Esto permite al navegador iniciar antes la resolución DNS y las conexiones de los recursos críticos.
• Configura Cloudflare para el rendimiento: Usa Cloudflare como tu proveedor de DNS y CDN. Combina una resolución DNS rápida con caché perimetral y soporte HTTP/3.

Subpartes del TTFB: Guías completas

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

• Identifica y corrige problemas del TTFB: El punto de partida diagnóstico para toda optimización del TTFB.
• Duración de espera: Redirecciones, colas del navegador y optimización HSTS.
• Duración de caché: Rendimiento de service workers, búsquedas en la caché del navegador y bfcache.
• Duración de conexión: Handshake TCP, optimización TLS, HTTP/3 y preconnect.
• Duración de petición: Tiempo de procesamiento del servidor, consultas a bases de datos y optimización del backend.