Cuando consumes una API REST con JavaScript, el navegador hace mucho trabajo silencioso por ti. Aprender a leer la pestaña Network del inspector te permite ver tiempos de carga, identificar qué recursos viajan por red y cuáles vienen del caché, y decidir dónde realmente vale la pena optimizar tu front-end.

Cómo preparo el proyecto Platzi Movies para inspeccionarlo

Antes de abrir cualquier herramienta, necesitas el proyecto corriendo localmente con tu propia API key.

El flujo es directo: clonas el repositorio desde la cuenta de Platzi en GitHub, entras a la carpeta y abres el editor con code -r ./ para reutilizar la ventana actual [01:30]. Al abrir el index.html en el navegador, vas a notar que el HTML carga, pero las películas y categorías no aparecen. Eso pasa porque The Movie DB exige una API key en cada consulta.

La solución sigue las instrucciones que dejaste en secrets.example.js:

• Crear un archivo secrets.js en la carpeta src.
• Declarar una constante API_KEY con el token que obtienes en themoviedb.org/settings/api.
• Confirmar que el archivo está en el .gitignore para no exponer tu llave en GitHub [03:40].

Con eso, al recargar, el scroll de tendencias del día, las categorías, el detalle de cada película y la búsqueda funcionan sin problema.

¿Por qué se ignora secrets.js en Git? Porque tu API key es privada. Subirla al repositorio público expone tu cuenta y permite que terceros consuman cuota a tu nombre.

Qué información me muestra la pestaña Network al cargar la app

La pestaña Network del DevTools registra cada recurso que tu HTML pide: CSS, fuentes de Google Fonts, imágenes, archivos JavaScript y, por supuesto, las llamadas fetch a la API [05:50].

Desde ahí puedes:

• Guardar un log histórico de todas las solicitudes.
• Deshabilitar el caché para pruebas limpias.
• Simular offline, internet lento o desesperantemente lento.
• Filtrar por tipo de recurso: CSS, JS, imágenes, fuentes o fetch.

Al filtrar por fetch, ves exactamente los endpoints que está consultando Platzi Movies. En el home aparecen dos: el de tendencias y el de la lista de categorías. Si entras a una categoría como Acción, aparece un endpoint distinto. Si vuelves al home, ya cargan tres llamadas porque sumas las anteriores [07:20].

Cómo forzar una recarga limpia para medir tiempos reales

Para medir cuánto tarda realmente una solicitud desde cero, haces clic derecho sobre el botón de recargar y eliges Empty cache and hard reload. Esa opción borra el caché y simula a un usuario que abre la aplicación por primera vez.

En esa primera carga, el endpoint de categorías pesa alrededor de 4.9 KB y el de tendencias unos 830 B, con sus respectivos tiempos de red.

Por qué el navegador ya cachea las llamadas a la API sin que yo escriba código

Aquí viene lo interesante. Si después del hard reload simplemente navegas entre tendencias, categorías y vuelves al home, la columna de tamaño deja de mostrar KB y empieza a decir disk cache, con tiempos de un milisegundo [10:15].

Eso significa que estás cargando esa información hasta 75 veces más rápido que en la primera solicitud. ¿La razón? Los navegadores aplican por defecto una estrategia de caché bastante decente para solicitudes HTTP que ya viste hace poco. No volvieron a pegarle al backend; reusaron la respuesta guardada en disco.

¿Qué es disk cache en la pestaña Network? Es la indicación de que el navegador no hizo una nueva solicitud HTTP, sino que tomó la respuesta previamente almacenada en disco, devolviéndola en milisegundos.

Cuál es la diferencia entre caché del navegador y memoization

La memoization la implementas tú en JavaScript: creas un objeto, guardas resultados a medida que los obtienes y, si vuelves a necesitarlos, los lees de ahí en lugar de volver a llamar a la API. Funciona excelente para cálculos como Fibonacci.

El caché del navegador, en cambio, lo gestiona el propio navegador en su memoria de disco. La diferencia clave es la persistencia entre recargas:

• Con memoization: si recargas la página, tu archivo de JavaScript se ejecuta de nuevo, el objeto se reinicia y pierdes lo guardado.
• Con caché del navegador: aunque recargues, el navegador conserva la respuesta y solo la libera tras mucho tiempo o si haces empty cache.

Por eso, para consumo de API REST en una app como Platzi Movies, el caché nativo gana. Ya está haciendo el trabajo de optimización HTTP por ti.

Dónde sí puedo optimizar mi front-end si las APIs ya están cacheadas

Si la solicitud HTTP ya viene resuelta, el verdadero margen de mejora está en otros recursos. Y aquí las imágenes son el ejemplo más visible.

Al recargar la app, la pestaña Network muestra que se intentan cargar decenas de imágenes, pero el navegador solo logra renderizar tres a la vez. Cargar todo lo demás de golpe es desperdicio puro [13:40].

Entonces, lo que realmente puedes optimizar desde el front-end incluye:

• Decidir qué partes de la aplicación necesitan hacer la solicitud y cuáles no.
• Cargar imágenes solo cuando entran en el viewport, técnica conocida como lazy loading.
• Implementar paginación inteligente para no traer listas gigantes.
• Usar local storage para persistir datos del usuario entre sesiones.
• Aplicar estas mismas decisiones a fuentes y otros assets estáticos.

La estrategia para Platzi Movies es clara: dejar que el navegador haga la magia con las llamadas HTTP y concentrar tu esfuerzo en los recursos pesados que sí dependen de tus decisiones de código.

¿Tú qué opinas? Si crees que en este proyecto valdría la pena forzar una estrategia distinta de caché o aplicar memoization manual, déjamelo en los comentarios. Y si usas un navegador distinto a Google Chrome, cuéntame con qué herramienta inspeccionas tus solicitudes.