preload: No es magia negra, no es un hack, no es SEO barato

preload no es un truco para engañar a Google.
No es un parche para webs lentas.
No es un botoncito que tocas “por si ayuda” y te olvidas.

Eso es lo que piensa el mediocre.

Lo que preload sí es:
la orden directa al navegador de cargar lo que de verdad importa, antes de que lo pida el parser,
la forma de ganar segundos valiosos en LCP y percepción de velocidad,
el grito de “esto es prioritario” en mitad del caos de peticiones.

Si no entiendes preload, tu optimización web es humo.

Acto I — La mentira de la medianía

Dogma reproducido:
“La web va lenta, mete un plugin de optimización. Seguro que ya mete preloads.”

Autopsia:
Un ecommerce con banners hero en slider. Las imágenes clave cargan tarde, el botón de compra aparece medio segundo después de la interacción. El diseñador dice: “Bah, es que son pesadas”.

Causa: el navegador carga assets en el orden que le da la gana.
Consecuencia: LCP disparado, experiencia torpe, métricas Core Web Vitals a la mierda.

Evidencia mínima:

Lighthouse: “Preload key requests” como warning.
Largest Contentful Paint > 4s.
Usuarios que abandonan en el primer scroll.

Smells — síntomas de optimización de pega:

Hero image cargando después del CSS crítico.
Fonts que aparecen con FOUT o FOIT porque nunca se priorizaron.
Recursos JS críticos escondidos detrás de 20 peticiones previas.

Contraejemplo rápido:

HTML
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>

Explicación:
Aquí no hay magia. Le dices al navegador: “trae esta fuente ya, la necesito sí o sí”. Resultado: tipografía lista antes del render.

Acto II — La verdad de preload

Visión:
No es un atajo. Es priorización explícita. Tú decides qué recursos entran primero en la autopista.

Modelo operativo:
Crítico → Preload → Render → Experiencia fluida.

Táctica 1 — imágenes clave

HTML
<link rel="preload" as="image" href="/images/hero.jpg">

Táctica 2 — fuentes sin parpadeo

HTML
<link rel="preload" as="font" href="/fonts/brand.woff2" type="font/woff2" crossorigin>

Táctica 3 — JS crítico (con cuidado)

HTML
<link rel="preload" as="script" href="/js/critical.js">

👉 Solo scripts pequeños y críticos. El resto, defer o async.

Demo mínima — con y sin preload

Sin preload:

HTML
<!-- Hero image tarda en aparecer -->
<img src="/images/hero.jpg" alt="Hero">

<!-- La font se carga después, FOUT evidente -->
<style>
  body { font-family: 'Brand', sans-serif; }
</style>
<link href="/fonts/brand.woff2" rel="stylesheet">

Con preload:

HTML
<!-- Precargamos la imagen clave -->
<link rel="preload" as="image" href="/images/hero.jpg">

<!-- Precargamos la fuente de marca -->
<link rel="preload" as="font" href="/fonts/brand.woff2" type="font/woff2" crossorigin>

<img src="/images/hero.jpg" alt="Hero">
<style>
  body { font-family: 'Brand', sans-serif; }
</style>
<link href="/fonts/brand.woff2" rel="stylesheet">

Acto III — El manifiesto

Principios no negociables:

preload solo se aplica a lo crítico, no a todo lo que se te ocurra.
preload mal usado puede joder el rendimiento (cola saturada).
Cada preload debe estar justificado por métricas (LCP, FCP, CLS).

Definición de hecho (DoD):

Fonts y hero image precargadas sin FOUT/FOIT.
LCP < 2.5s en móviles reales.
Ningún preload de recursos secundarios.

Métricas de guardarraíl:

LCP mejora medible tras el cambio.
≤ 5 recursos preload simultáneos.
No hay bloqueos de red por sobrecarga.

Plan de acción en 24h:

Audita tu web con Lighthouse.
Identifica imágenes y fonts críticas.
Añade preload solo a esas.
Revisa Core Web Vitals en móvil real.
Documenta qué recursos tienen permiso de preload.

Pablo Rodríguez: el crítico implacable

¿Qué opinas del uso de preload en webs modernas?

El preload es como el fast pass en un parque de atracciones. Si se lo das a todo el mundo, la cola se convierte en el mismo infierno. Si se lo das a quien toca, ganas segundos de gloria.
El 90% de los que meten preload lo hacen a lo loco: preload de todos los JS, preload de todas las imágenes, preload hasta del puto favicon. ¿Resultado? La web aún más lenta.

¿Por qué la mayoría lo usa como el culo? Porque cometen uno de estos crímenes capitales:

Todo va con preload. Una señal inequívoca de que no entiendes nada de la cadena de renderizado. Preload no es un cubo de basura donde tiras todo lo que «crees» que es importante. Es una orden directa y específica. Si priorizas todo, no priorizas nada.
Fonts sin crossorigin. Preloading de fuentes sin el atributo `crossorigin` es como pedir una cerveza y no llevar cartera. El navegador la descarga dos veces, genera un puto error y encima ralentiza el renderizado. Es un error básico que delata a un aficionado.
Preload de librerías externas enormes. ¿En serio quieres saturar la cola de prioridades con un jQuery de 100KB o un React entero? Eso no es optimizar, es pegarle un tiro al LCP en la cabeza. Los scripts grandes, si son críticos, se gestionan con defer o async, o se dividen en chunks. Preload es para el JS que no puede esperar ni un milisegundo.
preload de recursos no visibles o tardíos. Preload de una imagen del footer. Preload de un vídeo que se carga al hacer scroll. Es un despilfarro de recursos y de prioridad. Si no contribuye directamente al LCP o al FCP del usuario en el primer segundo, no merece un preload.

¿Significa esto que preload es una herramienta peligrosa?

No. Significa que es una herramienta potente que, en manos de un inepto, es más peligrosa que un mono con una navaja. Es como un bisturí. En manos de un cirujano, salva vidas. En manos de un carnicero, es una masacre.
Un profesional entiende la fisiología de la red. Sabe dónde cortar, qué vena cauterizar y qué órgano necesita flujo sanguíneo inmediato. El mediocre solo ve un botón grande que pone «Optimizar» y le da a ciegas.

¿Cómo se diferencia un «no medianía» usando preload?

Un «no medianía» usa el preload con la precisión de un francotirador.

Prioridad quirúrgica: Solo lo absolutamente esencial. La hero image, la fuente del título, un JS minúsculo para un componente crítico del LCP. El resto, que espere su turno.
Métricas como biblia: Cada preload está justificado por una mejora medible en LCP o FCP. No es una suposición, es un dato. Si no lo puedes medir, no lo uses.
Contexto: Sabe que el preload en mobile es aún más crítico, ya que la red es más lenta y los recursos son más limitados. Un preload de más en 3G es una sentencia de muerte para la web.
Sinergia: Entiende que preload no es un lobo solitario. Trabaja en equipo con `defer`, `async`, y la optimización de imágenes. No es la solución, es una parte de la estrategia global.

La sentencia

preload no es un juguete. Es cirugía de precisión.
Un profesional sabe dónde cortar.
Un mediocre apuñala a ciegas y se cree cirujano.