Minimizar la DNS Duration Subparte del Time to First Byte

Minimizar la DNS Duration Subparte del Time to First Byte

Este artículo forma parte de nuestra guía sobre el Time to First Byte (TTFB). La DNS duration es la tercera subparte del TTFB y representa el tiempo que el navegador dedica a resolver su nombre de dominio en una dirección IP. Para los visitantes primerizos que no tienen un registro DNS almacenado 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 de TTL de sus registros DNS.

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

• Waiting + Redirect (o waiting duration)
• Worker + Cache (o cache duration)
• DNS (o DNS duration)
• Connection (o connection duration)
• Request (o request duration)

¿Busca optimizar el Time to First Byte? Este artículo cubre la parte de DNS duration del Time to First Byte. Si busca comprender o corregir el Time to First Byte y no sabe qué significa DNS duration, lea qué es el Time to First Byte e identificar y corregir 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 de TTL.

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

¿Cómo funciona el DNS?

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

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

• Se comprueba la caché de DNS del navegador: Antes de realizar una consulta DNS, el navegador comprueba primero su propia caché de DNS para ver si ya tiene la dirección IP del dominio solicitado. Los navegadores modernos almacenan en caché los registros DNS durante un periodo determinado para mejorar el rendimiento al reducir la necesidad de búsquedas de DNS repetidas. Si el registro se encuentra en la caché del navegador, este puede utilizarlo inmediatamente sin realizar más consultas.
• Se comprueba la caché del sistema operativo: Si la caché del navegador no contiene el registro DNS necesario, la solicitud se pasa al resolutor de DNS del sistema operativo, a menudo llamado "resolutor stub". El sistema operativo también mantiene una caché de DNS y la comprobará 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 sistema operativo, se envía una consulta DNS recursiva a un resolutor de DNS, normalmente proporcionado por el proveedor de servicios de Internet (ISP) del usuario. Este resolutor actúa como intermediario, encargándose del proceso de consulta a otros servidores DNS para encontrar la dirección IP.
  • Root Name Servers (Servidores de nombres raíz): El resolutor contacta primero con un servidor de nombres raíz, que lo dirige al servidor de dominio de nivel superior (TLD) apropiado en función de la extensión del dominio (por ejemplo, ".com", ".org").
  • TLD Name Servers (Servidores de nombres TLD): El servidor TLD dirige entonces al resolutor al servidor de nombres autoritativo para el dominio específico.
  • Authoritative Name Server (Servidor de nombres autoritativo): Este servidor contiene los registros DNS del dominio y proporciona al resolutor la dirección IP.
• Devolución de la dirección IP: Una vez que el resolutor de 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 utilizando la dirección IP para cargar la página web solicitada.

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

Para los visitantes recurrentes, la búsqueda de DNS suele estar almacenada en caché en el navegador o en el sistema operativo, lo que reduce la DNS duration a casi cero. Para los visitantes primerizos, sin embargo, la búsqueda de DNS recursiva completa debe finalizar antes de que el navegador pueda proceder al paso de conexión TCP. Es por esto que el TTFB suele ser sensiblemente peor para los nuevos visitantes en comparación con los que regresan.

Usar dns-prefetch y preconnect para dominios de terceros

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

<!-- DNS prefetch para dominios de terceros -->
<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 en los que sepa que también tendrá que establecer una conexión TCP y TLS, utilice preconnect en su lugar, que incluye la resolución de DNS más el saludo de conexión (handshake):

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

Utilice dns-prefetch como respaldo para navegadores que no admiten preconnect:

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

Coloque estas indicaciones en el <head> de su HTML lo antes posible. Añada indicaciones solo para los dominios que su página utiliza realmente; añadir indicaciones para dominios no utilizados desperdicia recursos del navegador. Para obtener más técnicas de optimización relacionadas con la carga de recursos, consulte nuestra guía sobre 103 Early Hints.

How to Minimize DNS Impact on the TTFB

Utilizar 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 sencillas de reducir la latencia de DNS. Los proveedores de DNS premium como Cloudflare, Amazon Route 53 y Google Cloud DNS operan servidores en cientos de ubicaciones en todo el mundo. Cuanto más cerca esté el servidor DNS de su usuario, más rápida será la búsqueda.

He aquí 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 (fuente: benchmarks de DNSPerf). Para los visitantes primerizos, esto se traduce directamente en un TTFB más rápido. Para saber cómo configurar Cloudflare como su proveedor de DNS y CDN, lea nuestra guía para configurar Cloudflare.

Optimizar el Time to Live de la caché de DNS

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

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

¿Cuáles son los ajustes óptimos de TTL de DNS?

Al planificar una migración de DNS o un cambio de servidor, reduzca temporalmente su TTL a 5 minutos (300 segundos) al menos 24 horas antes de realizar el cambio. Esto asegura que, tras el cambio, los usuarios obtengan la nueva dirección IP rápidamente. Una vez que la migración se haya completado y verificado, vuelva a aumentar el TTL a un valor más alto para reducir la frecuencia de las búsquedas de DNS.

CONSEJO: si utiliza registros CNAME, considere implementar el CNAME flattening. El CNAME flattening es una técnica que le permite utilizar un registro CNAME en el nivel del dominio raíz (apex), resolviéndolo eficazmente en una dirección IP sin violar los estándares de DNS. Esto elimina una búsqueda de DNS adicional 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 de 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 de DNS, mejorando tanto la privacidad como la seguridad.

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

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

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

Medir la DNS Duration con JavaScript

Puede medir la subparte DNS duration del TTFB directamente en el navegador utilizando la API 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 DNS duration de 0ms en sus datos de RUM indica normalmente que la búsqueda de DNS se sirvió desde la caché del navegador o del sistema operativo (un escenario de visitante recurrente). Valores superiores a 50ms sugieren que el usuario tuvo que realizar una búsqueda de DNS recursiva completa, lo cual es común para los visitantes primerizos.

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

Para encontrar el impacto que experimentan los usuarios reales causado por la latencia de DNS, necesitará utilizar una herramienta de RUM como CoreDash. El 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 del Time to First Byte" para visualizar la parte de DNS del Time to First Byte.

Lectura adicional: Guías de optimización

Guías relacionadas:

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

Subpartes del TTFB: Guías completas

La DNS duration es una de las cinco subpartes del TTFB. Explore las otras subpartes para comprender el panorama completo:

• Identificar y corregir problemas de TTFB: el punto de partida del diagnóstico para toda la optimización del TTFB.
• Waiting Duration: redirecciones, colas del navegador y optimización de HSTS.
• Cache Duration: rendimiento del service worker, búsquedas en la caché del navegador y bfcache.
• Connection Duration: handshake TCP, optimización de TLS, HTTP/3 e preconnect.
• Request Duration: tiempo de procesamiento del servidor, consultas a la base de datos y optimización del backend.