Contenido del curso
Antes de optimizar...
Crítical Rendering Path
- 7

Entendiendo el Critical Rendering Path en Navegadores Web
11:11 min - 8

Optimización de JavaScript para mejorar rendimiento web
10:53 min - 9

Priorización de recursos CSS para mejorar rendimiento web
11:50 min - 10

Optimización de Carga de Recursos con Preload, Prefetch y Preconnect
Viendo ahora - 11

Optimización de Animaciones CSS para Mejorar el Renderizado
02:35 min
CSS
WebFonts
Imágenes, Iconos y SVG
- 15

Optimización de Imágenes para Web: Formatos y Herramientas Efectivas
15:32 min - 16

Optimización de Imágenes para Web: Uso de Tamaños y Formatos Adecuados
05:20 min - 17

Comparación entre WebFonts y SVG: Ventajas y Desventajas
08:58 min - 18

Lazy Loading de Imágenes: Técnicas y Estrategias Efectivas
10:14 min - 19

Carga Adaptativa de Imágenes con Gatsby y Web API
04:12 min
Aplicaciones JavaScript
- 20

Optimización de JavaScript para Producción Web
11:20 min - 21

Análisis y Optimización de Bundles con Webpack
11:25 min - 22

Optimización de Bundles en Proyectos Web con Webpack
17:14 min - 23

Code Splitting con Webpack: Optimización de Bundles en Proyectos Web
06:31 min - 24

Lazy Loading de Videos con JavaScript y Modales
21:44 min - 25

Event Propagation y Filtrado de Eventos en JavaScript
17:24 min - 26

Integración de Librerías en Proyectos JavaScript
14:57 min - 27

Optimización de Carga de Modales con Lazy Loading en Webpack
13:24 min - 28

Renderizado en Cliente vs. Servidor: Diferencias y Funciones
08:44 min - 29

Implementación de Server Side Rendering en NodeJS
19:41 min - 30

Optimización de Sitios con Static Site Generation
15:51 min
Caché
- 31

Funcionamiento de Caché y Redes de Distribución de Contenido (CDN)
05:50 min - 32

Configuración y despliegue de sitios web con Netlify y Github Actions
09:03 min - 33

Automatización de despliegues con Github Actions y Cron en Netlify
09:25 min - 34

Implementación de Caché con Service Workers en JavaScript
14:04 min
Performance Budget
Conclusiones
Optimización de Carga de Recursos con Preload, Prefetch y Preconnect
Resumen
Cuando conoces a fondo tu aplicación, puedes indicarle al navegador exactamente qué recursos necesita y cuándo los necesita. Existen tres estrategias poderosas para lograrlo: preload, prefetch y preconnect. Cada una resuelve un problema distinto de rendimiento y, usadas de forma inteligente, reducen tiempos de carga de manera notable.
¿Qué diferencia hay entre preload, prefetch y preconnect?
Estas tres técnicas se aplican mediante etiquetas <link> en el HTML y permiten adelantar trabajo que el navegador normalmente haría más tarde [0:08].
- Preload: es un fetch declarativo que le ordena al navegador descargar un recurso específico junto con el HTML. No es opcional, es una instrucción directa.
- Prefetch: le sugiere al navegador que un recurso podría necesitarse en el futuro. Es como decirle "tenlo presente para descargarlo luego" [0:24].
- Preconnect: resuelve de forma anticipada el handshaking de HTTP entre el navegador y un servidor externo. Cuando finalmente se necesite un recurso de ese servidor, la conexión ya estará establecida y se ahorran milisegundos valiosos [0:40].
¿Cómo usan preload y prefetch frameworks como Next.js?
Next.js es un framework de React que aplica estas estrategias de forma extremadamente agresiva para mejorar el rendimiento [1:06].
¿Qué hace Next.js con preload?
Al inspeccionar el HTML de una página construida con Next.js, se pueden encontrar múltiples etiquetas <link rel="preload"> [1:20]. Esto sucede porque Next.js divide el bundle de JavaScript en partes muy pequeñas mediante una técnica llamada code splitting [1:35]. Cada uno de esos módulos se marca con preload para que el navegador los descargue de inmediato y el usuario tenga la experiencia esperada.
¿Cómo funciona el prefetch en Next.js?
Desde la pestaña Network de las DevTools se observa algo muy interesante: cada vez que el cursor pasa sobre un enlace, Next.js dispara una orden de prefetching [2:15]. El navegador recibe la instrucción de que ese recurso se va a necesitar pronto. Así, entre el momento del hover y el clic, el browser ya ha adelantado trabajo descargando los recursos necesarios para la próxima página [2:30]. Gatsby aplica la misma lógica.
¿Cómo aplicar preconnect en un proyecto real?
Preconnect permite conectarse a dominios externos con anticipación para resolver la conexión HTTP antes de que se necesiten los recursos [3:00].
¿Cómo identificar los dominios externos correctos?
El primer paso es conocer los dominios a los que tu aplicación se conecta. En el ejemplo del proyecto, hay tres dominios externos [3:15]:
- fonts.googleapis.com para las fuentes de Google.
- Un dominio para resolver un polyfill.
- kitsu.io, la API que entrega los datos.
Sin embargo, el dominio desde el cual realmente llegan los archivos estáticos de las fuentes no es fonts.googleapis.com, sino fonts.gstatic.com [4:10]. Verificar esto en la pestaña Network es fundamental para apuntar al dominio correcto.
Para la API de Kitsu, aunque las imágenes llegan desde media.kitsu.io, este es solo un subdominio, por lo que basta con preconectarse a kitsu.io [5:10].
¿Cómo se escribe preconnect en el HTML?
Las etiquetas se colocan en el <head> del HTML, antes de las fuentes y antes de que inicie la carga de los demás recursos [4:30]:
html
<link rel="preconnect" href="https://fonts.gstatic.com"> <link rel="dns-prefetch" href="https://fonts.gstatic.com"> <link rel="preconnect" href="https://kitsu.io"> <link rel="dns-prefetch" href="https://kitsu.io">La combinación de preconnect con dns-prefetch asegura compatibilidad y resuelve tanto la búsqueda DNS como el handshake TLS de forma anticipada [4:45].
Sobre el polyfill, si conoces tu aplicación y asumes que tus usuarios ya cuentan con fetch nativo, puedes omitir esa preconexión [5:30]. Conocer a tu audiencia te permite tomar decisiones más inteligentes sobre qué optimizar.
Estas tres estrategias te dan el control para decidir qué tan agresivo quieres ser con la carga de recursos. Te invito a experimentar incorporando más etiquetas de preload, prefetch o preconnect en tu proyecto y observar cómo cambia el waterfall en la pestaña Network de las DevTools [5:50].