Optimización de la velocidad de resolución de DNS para SEO

Toda visita a su sitio empieza con una pregunta: ¿qué dirección IP corresponde a este nombre de host? Hasta que no se responde, el navegador no puede abrir una conexión, negociar TLS ni pedir un solo byte de HTML. Por eso la resolución DNS es el primer paso de la carga de una página, y por eso la “velocidad DNS para SEO” aparece tan a menudo en las auditorías de rendimiento.

La respuesta honesta, sin embargo, tiene más matices de lo que sugieren muchas guías. La consulta DNS suele representar una fracción pequeña del tiempo total de carga, se almacena en caché de forma intensiva y los buscadores no clasifican los sitios según sus tiempos de DNS. Lo que sí puede hacer el DNS es añadir, sin que nadie lo note, un retraso en las primeras visitas, en usuarios con redes lentas y en páginas que cargan recursos desde muchos dominios distintos. Esta guía explica de dónde viene ese retraso, cómo medirlo y qué correcciones merecen su tiempo.

Dónde encaja el DNS en la carga de una página

Cuando un navegador carga una página desde un nombre de host que no ha visitado recientemente, la secuencia es aproximadamente esta:

1. Consulta DNS: el nombre de host se traduce a una dirección IP.
2. Conexión TCP: se abre una conexión con esa dirección (o un handshake QUIC en HTTP/3).
3. Negociación TLS: se intercambian certificados y se establece el cifrado.
4. Petición y procesamiento en el servidor: el servidor genera la respuesta y empieza a enviarla.

El Time to First Byte (TTFB) abarca todos estos pasos. En un sitio bien gestionado, el procesamiento del servidor y los viajes de ida y vuelta por la red suelen pesar más; la parte del DNS se mide a menudo en unos pocos milisegundos cuando la respuesta está en caché y en decenas de milisegundos cuando no lo está. Solo se vuelve relevante cuando algo falla: un servidor autoritativo lejano o saturado, una larga cadena de alias o TTL tan cortos que anulan la caché.

Si es nuevo en la mecánica de la resolución, nuestra guía para principiantes sobre cómo funciona el DNS recorre paso a paso los servidores raíz, de TLD y autoritativos.

Latencia del resolutor frente a latencia autoritativa

En una consulta DNS intervienen dos tipos de servidores muy distintos, y cada uno tiene un responsable diferente.

El resolutor recursivo

Es el servidor al que pregunta el dispositivo del visitante: normalmente el resolutor de su proveedor de internet, el de su empresa o un servicio público. Responde desde su caché siempre que puede. Usted no lo controla y no puede hacer más rápido el resolutor de un visitante.

El servidor de nombres autoritativo

Cuando el resolutor no tiene la respuesta en caché, recorre la jerarquía y acaba preguntando a sus servidores de nombres autoritativos, los que figuran en los registros NS de su dominio. Su velocidad, ubicación y fiabilidad son responsabilidad suya, y por eso importa tanto la elección del proveedor DNS.

Cómo medir el tiempo de resolución DNS

Antes de cambiar nada, mida. Ir a ciegas suele llevar a cambios que no producen ninguna diferencia visible.

Con dig desde la línea de comandos

La herramienta dig muestra un “Query time” para cada petición. Consultar un resolutor público refleja lo que podría experimentar un visitante típico, mientras que consultar directamente su servidor autoritativo aísla el rendimiento de su proveedor.

# Through a resolver (may be cached)
dig www.example.com A

# Directly against your authoritative nameserver
dig @ns1.example-dns.net www.example.com A +norecurse

# Follow the full delegation path from the root
dig www.example.com A +trace

Ejecute cada consulta varias veces. La primera consulta al resolutor puede ser lenta y las siguientes rápidas gracias a la caché; esa diferencia ya le dice cuánto cuesta un fallo de caché. Si puede, repita la consulta autoritativa desde varias ubicaciones, porque un servidor que responde rápido desde Europa puede ser lento desde Asia.

Con las herramientas para desarrolladores del navegador

En Chrome o Edge, abra DevTools, vaya al panel Network, seleccione una petición y abra la pestaña Timing. La línea “DNS Lookup” indica cuánto tardó la resolución para esa conexión. Firefox muestra una fase similar llamada “DNS Resolution”. Desactive la caché y use una ventana privada para ver una consulta en frío, pero recuerde que el sistema operativo puede seguir guardando respuestas en caché. Herramientas de laboratorio como WebPageTest también muestran el tiempo de DNS de cada nombre de host en sus diagramas de cascada.

Con datos de campo

La Navigation Timing API expone domainLookupStart y domainLookupEnd, de modo que las herramientas de monitorización de usuarios reales pueden informar del tiempo de DNS de visitantes auténticos. Los datos de campo son la visión más fiel, porque reflejan redes, dispositivos y estados de caché reales.

TTL: equilibrio entre velocidad y flexibilidad

Cada registro DNS lleva un Time To Live, el número de segundos durante los que los resolutores pueden guardarlo en caché. Un TTL largo significa más aciertos de caché y menos viajes a sus servidores autoritativos; uno corto hace que los cambios se propaguen antes, pero más visitantes pagan el coste de una consulta nueva.

• Registros estables, como NS y MX o los registros A de servidores que rara vez cambian, pueden usar sin problema TTL de varias horas o de un día.
• Registros que quizá deba cambiar con rapidez durante una migración o una conmutación por error pueden bajarse temporalmente, por ejemplo a 300 segundos, uno o dos días antes del cambio.
• TTL muy bajos en todas partes suelen ser un error, salvo que su proveedor los use deliberadamente para dirigir el tráfico.

Tenga en cuenta que algunos resolutores aplican sus propios tiempos mínimos o máximos de caché, así que el TTL es una indicación fuerte, no una garantía absoluta.

Acorte las cadenas CNAME

Un CNAME apunta un nombre a otro. Cada salto de la cadena puede exigir otra consulta si el destino no está en caché, y los destinos suelen estar en zonas distintas servidas por proveedores distintos. Una configuración en la que www apunta a un nombre de la CDN, que apunta a un nombre regional, que finalmente se resuelve en un registro A, puede implicar varias resoluciones independientes con la caché vacía.

Pasos prácticos:

• Audite sus nombres de host importantes con dig y cuente los saltos CNAME.
• Elimine los alias intermedios innecesarios que haya creado usted mismo.
• En el ápice de la zona, donde no se permite un CNAME estándar, use la función ALIAS, ANAME o de aplanamiento de CNAME de su proveedor, que devuelve directamente una dirección.
• Reduzca al mínimo los nombres de host de terceros, porque cada dominio distinto necesita su propia consulta.

Indicaciones de recursos: dns-prefetch y preconnect

Los navegadores le permiten adelantar el trabajo de DNS para los nombres de host que sabe que una página va a necesitar.

<link rel="dns-prefetch" href="https://cdn.example.net">
<link rel="preconnect" href="https://fonts.example.org" crossorigin>

• dns-prefetch solo resuelve el nombre. Es barato y está ampliamente soportado, así que conviene para nombres de host que probablemente se necesiten.
• preconnect resuelve el nombre y además abre la conexión TCP y TLS. Ahorra más tiempo pero consume recursos, así que limítelo a unos pocos orígenes críticos que se necesiten al principio de la carga.

Hacer preconnect a muchos orígenes puede salir caro, porque compite con peticiones más importantes. Use estas indicaciones para orígenes de terceros que estén en su ruta de renderizado crítica, como un servicio de fuentes o una CDN de imágenes, y no para su nombre de host principal, que el navegador ya está resolviendo.

DNS y Core Web Vitals

Las Core Web Vitals miden el Largest Contentful Paint (LCP), el Interaction to Next Paint (INP) y el Cumulative Layout Shift (CLS). El DNS no es ninguna de ellas ni es una señal de posicionamiento directa. Su influencia es indirecta: una resolución más lenta aumenta el TTFB, y el TTFB forma parte del LCP. Las consultas para una imagen principal alojada en otro dominio también pueden retrasar el LCP.

El DNS prácticamente no afecta al INP ni al CLS. Así que, si sus datos de campo muestran un LCP deficiente, revise el tiempo de DNS en la cascada, pero espere mayores mejoras de los tiempos de respuesta del servidor, la optimización de imágenes y los recursos que bloquean el renderizado. Considere el DNS parte de una buena higiene técnica, junto con un alojamiento fiable y certificados válidos.

Cómo elegir y supervisar un proveedor DNS

En el lado autoritativo, busque un proveedor con servidores en muchas regiones (normalmente mediante anycast), un historial de disponibilidad sólido, soporte para funciones modernas como DNSSEC y alias en el ápice, y una documentación clara. El DNS gratuito de su registrador puede ser perfectamente suficiente para sitios pequeños; las audiencias grandes o internacionales pueden beneficiarse de un proveedor especializado.

La velocidad también depende de que lo básico siga en buen estado. Un dominio caducado o un plan de alojamiento DNS vencido no hace que la resolución sea lenta: hace que falle por completo. Puede comprobar qué servidores de nombres usa un dominio, junto con sus datos de registro y alojamiento, con la consulta WHOIS y de hosting de TLDix, y reunir en un solo lugar las fechas de renovación de dominios, certificados SSL y alojamiento para que nada caduque sin que se dé cuenta.

Lista de comprobación breve

1. Mida el tiempo de DNS con dig, DevTools y, a ser posible, datos de usuarios reales.
2. Confirme que sus servidores de nombres autoritativos responden rápido desde las regiones donde está su audiencia.
3. Defina TTL acordes con la frecuencia real con la que cambian los registros.
4. Elimine saltos CNAME innecesarios y use el aplanamiento en el ápice cuando haga falta.
5. Reduzca el número de nombres de host de terceros distintos.
6. Añada dns-prefetch o preconnect solo para orígenes externos críticos.
7. Supervise la configuración de los servidores de nombres y las fechas de renovación para que la resolución nunca se rompa.

Ninguno de estos pasos transformará por sí solo su posicionamiento. En conjunto, eliminan una fuente de retraso evitable desde el inicio mismo de cada visita, que es exactamente lo que persigue un trabajo de rendimiento centrado en las personas.