\n \n \n\nLo bueno de esto es que el parámetro no afecta al nombre del fichero. Todo lo que vaya después de la interrogación es independiente del nombre. En el ejemplo anterior, siempre se hace referencia al fichero 'miestilo.css', así que no te líes a cambiar el nombre de tus ficheros. Con añadir el parámetro en la URL vale.\n\nDe hecho, si ya eres un profesional más avanzado y has probado React o Angular, te habrás dado cuenta de que los CSS y los JS que obtienes tienen incluidos unos \"codiguitos\" estilo main.54ds6.js. Esto es precisamente para saltarse la caché cuando haya un cambio y solo descargar los contenidos nuevos.\n\nOtra opción que tienes si no quieres añadir parámetros es usando la directiva ****no-cache****. Recuerdas que te dije que no significaba lo que daba a entender por el nombre. Recapitulando, los recursos con la directiva ****no-cache**** permiten al navegador cachear un recurso pero siempre comprobando que no hay una versión más reciente. Lo malo de esta directiva es que siempre hay una petición al servidor. Lo bueno, es que si el recurso no ha cambiado, la respuesta será un 304 Not modified y sin cuerpo; traduciendo, que en vez de kB de tamaño, apenas serán unos bytes. Siempre es más rápido enviar bytes que kilobytes.\n\n¿Y cómo sabe el navegador o el servidor si el recurso está actualizado 🤔? Pues hay varias formas de hacerlo: usando la cabecera If-Modified-Since o usando la cabecera ETag.\n\nLa cabecera If-Modified-Since (que se traduce por \"si no ha sido modificado desde\") la manda el navegador. Es muy útil cuando se está pidiendo estáticos (que existen en el servidor como ficheros). El navegador envía la petición para comprobar si el recurso que tiene en caché es el último igual que con cualquier petición, pero añade esta cabecera indicando la fecha y hora en la que guardó el recurso en la caché. El servidor, comprobará la fecha del fichero y si no ha cambiado desde entonces, devolverá un ****304 Not Modified.**** El navegador cuando lee esta respuesta entiende que sí tiene la última versión, por lo que puede usarla. Si por el contrario el servidor detecta que hay una versión más reciente, devolverá un ****200 Ok**** y el propio recurso en la misma petición. El navegador entiende que debe borrar el recurso que tiene guardado en su caché y reemplazarlo por este nuevo que está enviando el servidor. Este proceso se repetirá siempre tal cual. Según el navegador detecte que necesita ese recurso y comprueba que existe en la caché con la directiva ****no-cache****, hará la petición esperando un 200 o un 304.\n\nLa otra posibilidad que tienes es usar la cabecera ETag. Funciona de forma similar a If-Modified-Since, pero en este caso no contiene fechas, sino cadenas de texto. Cuando el servidor envía un recurso le añade la cabecera ETag cuyo valor es aleatorio pero permite identificar el recurso (la firma de su contenido mediante algún hash, la fecha de generación, la versión, etc). Una vez que el navegador quiere comprobar si el recurso es la última versión envía la petición con la cabecera ETag según la envió el servidor. El servidor comprueba así si el recurso ha cambiado de versión y la cadena de texto coincide con la que envió el cliente. Si coincide, el servidor devuelve un 304; si no, un 200. No deberías tener que preocuparte de generar un ETag, los principales servidores web lo harán por ti. Quédate con el concepto de que el servidor sabe a través de ese ETag a qué versión del fichero se refiere.\n\n## Cómo aplicar la caché HTTP a mi web\n\nPues ya tienes toda la teoría que necesitas para empezar y para volar durante un tiempo. Pero, ¿y la práctica?. Pues depende del servidor web que estés utilizando, aunque seguramente sea Apache o Nginx. Si es Apache, tienes toda la información sobre caché en la [web oficial](http://web.archive.org/web/20201230082813/https://httpd.apache.org/docs/2.4/caching.html) (versión 2.4) o en muchos blogs, pero básicamente es usar el módulo Header de Apache (aunque puedes usar expires, pero no me hace mucha gracia; prefiero establecerlo a mano):\n\n