Punto de partida. Actividad «Optimización y comparación de la web», sesión 4 de 6. Abre el avance de la sesión anterior; los pasos de hoy indican qué conservar y qué completar. La guía de arranque permite preparar las herramientas sin depender de otros módulos.
Se explica
10 minutos · contexto, explicación y ejemplo
Las dependencias y los recursos externos añaden transferencias y ejecución. Que un archivo parezca grande no demuestra que sobre: puede sostener una función de la tienda. Revisaremos usos concretos antes de retirarlo.
La caché permite reutilizar respuestas; la compresión reduce tamaño durante el transporte. Su configuración pertenece al servidor y hoy se estudia mediante ejemplos, no se exige implantarla en el servidor local sencillo. La misma idea de evitar trabajo innecesario sirve para datos: pedir solo lo que se necesita, sin programar una API nueva en esta actividad.
Consultar ejemplos y conceptos de esta sesión
¿Hay que descargar siempre lo mismo?
Un usuario entra hoy y descarga el logotipo. Cambia de página. ¿Hace falta volver a descargar exactamente el mismo archivo? No necesariamente. Para eso está la:
Caché
Guardar temporalmente un recurso para reutilizarlo sin volver a pedirlo.
Primera visita
Servidor → logo.webp → navegador.
Siguientes visitas
Caché → logo.webp. Sin salir a la red.
Esto reduce peticiones, transferencia y latencia, a costa de un problema propio: si modificamos style.css y el navegador conserva la versión antigua, el usuario ve una web rota. Por eso hay que gestionar cuándo un recurso deja de ser válido.
No entraremos en configuración avanzada. Basta con entender qué problema resuelve la caché y qué problema crea.
Compresión
Los recursos de texto —HTML, CSS, JavaScript, JSON— pueden comprimirse durante la transferencia con tecnologías como gzip o Brotli.
- Archivo
- Comprimir
- Transferir menos datos
- Descomprimir
No todo admite una segunda compresión: un AVIF llega ya fuertemente comprimido, y volver a comprimirlo apenas aporta nada mientras consume tiempo de CPU en los dos extremos.
La optimización también tiene coste. No hacemos trabajo que no produce un beneficio razonable.
Datos: el mismo principio, en el backend
Un endpoint que devuelve 50.000 productos cuando la interfaz muestra 20:
GET /productosUna solución es la paginación: pedir solo lo que hace falta ahora.
GET /productos?page=1&size=20El mismo criterio se aplica a las columnas. Si necesitamos nombre, precio e imagen, quizá no hacía falta:
SELECT *Vuelve a aparecer el principio de la unidad: procesar y transferir solo lo necesario.
Se trabaja
45 minutos · trabajo guiado sobre la actividad
- Selecciona un script o recurso externo de la medición. Localiza dónde se incluye y qué función visible aporta. Si no lo sabes, investiga antes de borrarlo.
- Prueba una mejora acotada sobre un recurso del cliente: retirar una inclusión confirmada como innecesaria o posponer un elemento que no se necesita al inicio. Guarda el punto anterior.
- Repite el recorrido que utiliza ese recurso y revisa consola y Red. Si se rompe una función, restaura el cambio y registra por qué la propuesta no era adecuada.
- Compara dos recomendaciones, una propia y otra del asistente o de la ficha preparada. Clasifícalas en aceptar, rechazar o investigar con un motivo observable. La guía de revisión explica el procedimiento sin remitir a Digitalización.
- Resuelve los ejemplos de caché, compresión y datos del material de consulta: indica qué recurso ahorrarían y quién tendría que configurar la solución. Separa estas propuestas de los cambios que sí has implementado.
Cierre
5 minutos · comprobar el resultado
Al terminar la sesión:
La evidencia distingue una optimización real del cliente de una propuesta para el servidor. No se exige Nginx, paginación de Spring ni CI.