...
logo de alojamiento web

DNS prefetching y preloading: optimización de la velocidad del sitio web

DNS prefetching y preloading acortan activamente el tiempo hasta el primer contenido visible activando DNS, TCP y TLS con antelación y proporcionando archivos críticos por adelantado. Le mostraré cómo utilizar Prefetching de DNS, Preconectar y precargar el Velocidad del sitio web notablemente, incluido el código, la configuración de WordPress y las prioridades probadas.

Puntos centrales

  • Prelectura de DNSLa resolución temprana de nombres reduce la latencia.
  • PreconectarAbra DNS, TCP y TLS por adelantado.
  • PrecargaPriorizar activamente los expedientes críticos.
  • PriorizaciónPocos dominios, pero decisivos.
  • MonitoreoComprueba los efectos en la cascada.

DNS prefetching: breve explicación

Con Prefetching de DNS el navegador resuelve de antemano la IP de un dominio antes de cargar un archivo, con lo que se ahorran entre 20 y 250 ms por dominio, especialmente en conexiones móviles con mucho tráfico. Latencia. En la parte superior de la página, establezco las sugerencias para los hosts externos que necesito, por ejemplo, para fuentes, análisis o una CDN. El navegador realiza la búsqueda de DNS en segundo plano y acorta así el camino crítico hasta la primera renderización. Los navegadores modernos a veces utilizan el prefetching de forma automática, pero yo me aseguro del efecto con una pista clara en la cabeza. Esto reduce los viajes de ida y vuelta, estabiliza el inicio temprano de la renderización y acelera el proceso de renderización. Core Web Vitals.

Diferencia: DNS prefetching vs. preconnect

Prefetch sólo activa el DNS-names, mientras que Preconnect también abre el handshake TCP y TLS y mantiene la conexión caliente. Para hosts críticos, como un CDN para renderizar CSS o fuentes web, prefiero Preconnect a sólo Prefetch. Lo uso con moderación, ya que cada socket abierto ocupa espacio en el navegador. El atributo crossorigin pertenece a todos los hosts con CORS para no ralentizar las peticiones posteriores. Puede encontrar una visión clara de la selección y la secuencia en el compacto Guía de Prefetch.

Precarga: Precarga de archivos específicos

Cargas de precarga específicas Archivos activamente en la caché antes de que el analizador sintáctico los solicite normalmente, acelerando así FCP y LCP. Sólo lo uso para recursos que son definitivamente necesarios, como CSS crítico, imágenes hero o fuentes WOFF2. El atributo prioridad de búsqueda dirige la ponderación hacia arriba sin desplazar completamente otras transferencias importantes. Compruebo que el tipo MIME, el atributo as y el uso real coincidan, de lo contrario pierdo ancho de banda. HTTP/3 es un buen complemento, como se describe en el artículo sobre HTTP/3 y precarga descrito.

Aumento del rendimiento del alojamiento

Una rápida Alojamiento aumenta el efecto de las sugerencias porque los RTT bajos, HTTP/3 y una CDN cercana reducen los tiempos de espera por etapa. Regularmente veo que TTFB baja hasta un segundo cuando DNS, TCP y TLS empiezan a precalentarse y el Origen responde rápidamente. En dispositivos móviles con alta latencia, esto compensa doblemente porque cada ida y vuelta ahorrada va directamente al LCP. Presto atención al manejo estable de TLS, al grapado OCSP y a una configuración TLS ajustada. De esta forma, el navegador hace un uso óptimo de sus pocas conexiones simultáneas y acelera el Velocidad del sitio web.

Comparación rápida: ¿qué tecnología para qué?

La siguiente tabla resume el efecto, el uso y las etiquetas de ejemplo y me ayuda a elegir la medida adecuada para cada host. Combino prefetch para la anchura, preconnect para hosts críticos y preload para archivos esenciales. Mantengo bajo el número de conexiones abiertas simultáneamente. Esto deja espacio suficiente para los descubrimientos del analizador y los activos críticos tardíos. Esta visión general toma decisiones sobre Priorización más fácil.

Tecnología ¿Qué ocurre? Uso típico Ejemplo de etiqueta Impacto en FCP/LCP
Prelectura de DNS Temprano Resolución del nombre Anfitriones externos con solicitudes posteriores <link rel="dns-prefetch" href="//fonts.googleapis.com"> Moderadamente positivo, dependiendo de la latencia
Preconectar DNS + TCP + TLS precalentar CDN, fuentes, API críticas <link rel="preconnect" href="https://cdn.example.com" crossorigin> Claramente positivo, ahorra viajes de ida y vuelta
Precarga Archivo activo precarga CSS crítico, WOFF2, Hero-Image <link rel="preload" as="style" href="/critical.css"> Muy positivo, si se elige correctamente

Integración con WordPress: limpia y fácil de mantener

En WordPress, establezco las pistas muy al principio del Jefe, para que el navegador los vea antes que el cuello de botella del analizador. Desduplico hosts, compruebo la presencia de https y añado crossorigin sólo si es necesario. El siguiente código coloca las entradas en la parte superior, lo que maximiza el efecto. También compruebo después de los despliegues si se han añadido nuevos hosts externos. Esto mantiene la lista de sugerencias ordenada, actualizada y eficiente.

function add_dns_prefetch() {
    $domains = ['//fonts.googleapis.com', '//www.googletagmanager.com', '//cdn.webhoster.de', 'https://fonts.gstatic.com'];
    1TP4Impresos = [];
    foreach ($domains as $domain) {
        $key = preg_replace('#^https?:#', '', $domain);
        if (isset($printed[$key])) { continue; }
        $printed[$key] = true;
        echo '' . "\n";
        if (strpos($domain, 'https://') === 0) {
            echo '' . "\n";
        }
    }
}
add_action('wp_head', 'add_dns_prefetch', 1);

Buenas prácticas: concisas pero eficaces

Limito Preconnect a tres o cinco Anfitriones, de lo contrario, el navegador bloqueará demasiados sockets antes de tiempo. Siempre coloco las sugerencias al principio de la cabecera, seguidas de las precargas, luego los estilos y los scripts. Para las fuentes, combino Preconnect con font-display: swap, para que el texto aparezca inmediatamente y el CLS se mantenga bajo. Me aseguro de que los archivos de precarga se utilicen con garantías, de lo contrario estoy malgastando ancho de banda y no doy prioridad a lo que se necesita. En el caso de los scripts de terceros, compruebo críticamente si cada Dominio es necesario.

Medición y seguimiento: hacer visible el éxito

En la pestaña Red del DevTools, miro el orden de DNS, TCP y TLS y comprueba si empiezan antes que antes. Una comparación del antes y el después en la cascada muestra claramente si las sugerencias están funcionando. Yo utilizo Lighthouse o PageSpeed Insights para observar FCP, LCP y CLS, así como la tendencia TTFB. WebPageTest también proporciona una vista de conexión y tiras de película que documentan el inicio del renderizado. Después de cambios importantes, repito la medición y elimino los archivos obsoletos. Anfitriones de la lista de sugerencias.

HTTP/3, QUIC y coalescencia de conexiones

Con HTTP/3 vía QUIC ahorro adicional Viajes de ida y vuelta, porque la configuración de la conexión, la gestión de pérdidas y la multiplexación funcionan de forma más eficiente. Compruebo si mi CDN y mi Origen ofrecen HTTP/3 y sigo utilizando Preconnect de forma selectiva. Connection coalescing reduce el número de conexiones separadas si los certificados y las IP coinciden. Esto permite a los hosts con el mismo certificado servir a varios subdominios a través de una conexión compartida. Conexión. En general, la ruta de renderizado temprana se beneficia significativamente, especialmente con muchos archivos pequeños.

Combinar el calentamiento CDN y el prefetch

Caliento mi CDN cuando espero picos de tráfico y lo combino con Prelectura y Preconnect para hosts Edge. Esto significa que los objetos importantes se almacenan en la caché Edge y los apretones de manos ya están preparados. Esto reduce las latencias, especialmente en las llamadas iniciales y en condiciones de movilidad. Encontrará instrucciones prácticas en el artículo sobre Calentamiento CDN, que me gusta utilizar como lista de comprobación. Antes de los lanzamientos, compruebo los índices de aciertos de la caché y observo el TTFB-desarrollo.

Gobernanza: mantener actualizada la lista de sugerencias

Dirijo un breve Inventario de todos los hosts externos y compruebo trimestralmente si se han añadido nuevos scripts, fuentes o imágenes. Borro las integraciones eliminadas junto con la sugerencia para mantener la lista aligerada. Para cada host, anoto el propósito, la criticidad y la tecnología utilizada (prefetch, preconnect o preload). Introduzco inmediatamente los cambios en la CDN o las fuentes para que no queden entradas huérfanas. De este modo mantengo el control, reduzco los gastos generales y garantizo la coherencia. Actuación.

Compatibilidad con navegadores, heurística y límites

Calculo que las sugerencias del navegador como Señales no como un comando. Con poco ancho de banda, un ahorrador de datos activo o en la pestaña de fondo, el navegador puede ajustar las prioridades o estrangular las sugerencias. Safari es más conservador con las preconexiones, Firefox tiene una heurística diferente para las cachés DNS en algunos casos, y las variantes móviles reducen los sockets paralelos. Por eso formulo sugerencias preciso y evitar el exceso de señalización: un número reducido de hosts, clara como-valores, correctos tipo-información. En cuanto a las fuentes, presto atención a crossorigin, De lo contrario, existe el riesgo de doble búsqueda o de bloqueo tardío de CORS. Si quiero controlar el prefetch completamente, puedo usar <meta http-equiv="x-dns-prefetch-control" content="on"> o fuera de influyen en la heurística automática.

Cabecera HTTP y 103 pistas tempranas

Además de las etiquetas HTML utilizo Cabecera de enlace, para que las sugerencias lleguen con la primera respuesta del servidor - ideal para el renderizado del lado del servidor. 103 Early Hints envía incluso estas cabeceras antes de de la respuesta 200 final y ganar así decenas de milisegundos en las líneas largas.

# NGINX: Preconexión y precarga mediante encabezado de enlace
add_header Link '; rel=preconnect; crossorigin' siempre;
add_header Link '; rel=preload; as=style; fetchpriority=high' siempre;
add_header Link '; rel=preload; as=font; type=font/woff2; crossorigin' siempre;

# Apache (htaccess)
Header add Link '; rel=preconnect; crossorigin'
Header add link '; rel=preload; as=image'

¿El servidor admite 103 Primeras pistas, También envío las cabeceras de los enlaces antes de tiempo. Importante: Conservo la lista corto, porque cada entrada genera un esfuerzo de análisis y posibles aperturas de conexión.

SPA y Service Worker: precarga de rutas y datos

Para aplicaciones de una sola página, muevo las sugerencias basado en el estadoEn cuanto el héroe es visible, inicio una precarga específica para la siguiente ruta (fragmento JS, imagen crítica, esquema API). En el Service Worker, puedo almacenar en caché los resultados de la precarga y utilizarlos después de los eventos de navegación. Defino criterios de cancelación claros (pestaña oculta, CPU sobrecargada, red débil) para que la precarga no se convierta en un factor de coste. Para los módulos ES establezco carga previa de módulos, para que la cadena de dependencia no se ralentice.

<link rel="modulepreload" href="/assets/js/app.entry.js">
<script>
// Vorsichtige SPA-Vorladung
if (navigator.connection?.saveData !== true) {
  const idle = window.requestIdleCallback || ((cb) => setTimeout(cb, 300));
  idle(() => {
    const l = document.createElement('link');
    l.rel = 'preload';
    l.as = 'script';
    l.href = '/assets/js/route-checkout.js';
    document.head.appendChild(l);
  });
}
</script>

Seguridad, protección de datos y directrices

Considero los marcos políticos: un estricto CSP puede bloquear las precargas si fuente-src, style-src o img-src no permiten los objetivos. crossorigin es obligatorio para las fuentes, de lo contrario la caché no funcionará en todos los orígenes. Con terceros sensibles, no difundo ninguna preconexión si pudiera eliminar el dominio en el futuro: cada pista es una señal para el navegador y puede acelerar los scripts de rastreo. También compruebo Guardar datos y Ahorro de datosEn estos modos, reduzco la agresividad de las precargas y sólo dejo activo el DNS prefetch para los hosts centrales.

Profundizar en la práctica de la medición: API de cronometraje y registros

Además de las cascadas, utilizo el API de temporización de recursos y PerformanceObservercon el fin de en el campo para medir si las pistas llegan al analizador sintáctico y cómo domainLookupStart, connectStart y secureConnectionStart mover. Esto me permite reconocer si un Preconnect ha sido realmente utilizado o ha sido rechazado por el navegador.

<script>
new PerformanceObserver((list) => {
  for (const e of list.getEntriesByType('resource')) {
    if (e.name.includes('fonts.gstatic.com')) {
      console.log('DNS:', e.domainLookupEnd - e.domainLookupStart,
                  'TLS:', e.secureConnectionStart > 0 ? e.connectEnd - e.secureConnectionStart : 0,
                  'Start:', e.startTime.toFixed(1));
    }
  }
}).observe({ type: 'resource', buffered: true });
</script>

Comparo estos datos con los registros del servidor y las estadísticas de la CDN (tasa de reanudación de TLS, cuota de HTTP/3, visitas a la caché). Si veo que TLS casi siempre se reanuda, puedo reducir el número de preconexiones activas y liberar ranuras para las detecciones del analizador sintáctico.

WordPress en profundidad: uso limpio de los filtros del núcleo

WordPress ya viene con una infraestructura de sugerencias de recursos. Me adhiero a wp_resource_hints, en lugar de imprimir yo mismo HTML sin procesar, y sólo paso objetivos deduplicados. Para la precarga configuro wp_enqueue_style/wp_enqueue_script y añada el como-atributos mediante wp_style_add_data.

// Preconexión y prefetch DNS mediante filtro de núcleo
add_filter('wp_resource_hints', function($urls, $relation_type) {
    $critical = [
        'preconnect' => ['https://fonts.gstatic.com', 'https://cdn.example.com'],
        'dns-prefetch' => ['//fonts.googleapis.com', '//www.googletagmanager.com', '//cdn.webhoster.de'].
    ];
    if (!empty($critical[$relation_type])) {
        foreach ($critical[$relation_type] as $u) {
            if (!in_array($u, $urls, true)) { $urls[] = $u; }
        }
    }
    return $urls;
}, 10, 2);

// Encargar la precarga correctamente
add_action('wp_enqueue_scripts', function() {
    wp_enqueue_style('critical', get_stylesheet_directory_uri() . '/assets/css/critical.css', [], null);
    wp_style_add_data('critical', 'preload', true);
    wp_style_add_data('critical', 'as', 'style');

    wp_register_style('font-inter', false);
    wp_enqueue_style('font-inter');
    add_action('wp_head', function() {
        echo '' . "\n";
    }, 2);
}, 1);

También me aseguro de que los plugins de optimización (aplazar, combinar) No deje que se le escapen pistas al analizador sintáctico. Tras la activación, compruebo si se mantiene el orden en la cabeza y si no hay precargas duplicadas.

Resolución de problemas y antipatrones

  • Demasiadas conexiones previasMás de 3-5 hosts desperdician enchufes. Acorto a la primera crítica Objetivos (fuentes/CDN/API).
  • Equivocado como/tipo: A as="fuente" sin type="font/woff2" puede dar lugar a una prioridad incorrecta o a solicitudes duplicadas.
  • Precargas no utilizadas: Cada recurso no utilizado atasca la línea. Elimino las precargas que no se utilizan con seguridad en el sobre-pliegue.
  • Crossorigin olvidado: Con fuentes o CDN externas, esto conlleva problemas de CORS y pérdida de caché.
  • Orden HTMLLas sugerencias deben colocarse al principio de la cabecera. Precarga antes de los estilos, luego renderiza CSS, luego JS crítico.
  • Imagesrcset sin tallasAñado tamaños de imagen, para que el navegador seleccione correctamente y las descargas sigan siendo sencillas.
<link rel="preload" as="image" href="/assets/img/hero.webp"
      imagesrcset="/assets/img/hero.webp 1x, /assets/img/[email protected] 2x"
      imagesizes="(min-width: 1024px) 1200px, 100vw">

Establecer prioridades bien fundadas

Decido en función de algunas cuestiones: 1) ¿Está garantizado el anfitrión/activo antes de tiempo? ¿es necesario? 2) A qué altura ¿es la latencia (móvil, global, CDN fría)? 3) ¿Existen alternativas? (subconjunto CSS en línea, autoalojamiento de fuentes)? 4) ¿Es reutilizable la conexión? (coalescencia, H3, reanudación)? 5) Deteriorado los descubrimientos del analizador de medidas? Sigue: Prefetch para ganancias amplias y favorables; preconectar selectivamente para calentamientos; precargar sólo para garantizado archivos necesarios con una mecanografía limpia y una priorización correcta.

Resumen

Utilizo DNS Prefetching para ganancias de latencia amplias y favorables, preconnect para unos pocos hosts pero centrales y preload para archivos cuya necesidad está garantizada. La secuencia en la cabeza y una selección parsimoniosa producen los mayores efectos. Mido cada cambio, compruebo las cascadas y ajusto la lista de sugerencias con regularidad. En combinación con HTTP/3, una CDN cercana y una priorización inteligente de los recursos, aumento visiblemente el FCP y el LCP. Así es como utilizo la optimización del navegador dns para aumentar de forma eficaz y sostenible el Velocidad del sitio web.

Artículos de actualidad