Cache busting a través de params

Queremos almacenar en caché los desplomes de producción, pero no perder un montón de tiempo pensando en un sistema para hacerlo. Mi pensamiento era aplicar un parámetro al final de los archivos css y js con el número de versión actual:

<link rel="stylesheet" href="base_url.com/file.css?v=1.123"/>

Dos preguntas: ¿Romperá efectivamente la memoria caché? ¿El parámetro hará que el navegador nunca almacene en caché la respuesta de esa URL ya que el parámetro indica que se trata de contenido dinámico?

El parámetro ?v=1.123indica una cadena de consulta, por lo que el navegador va a pensar que es un nuevo camino de, por ejemplo, ?v=1.0. Por lo tanto, hace que se cargue desde el archivo, no desde la caché. Como quieras.

Y el navegador asumirá que la fuente permanecerá igual la próxima vez que llame ?v=1.123y debería almacenarla en caché con esa cadena. Por lo tanto, permanecerá en caché, independientemente de cómo esté configurado su servidor, hasta que se mueva a ?v=1.124o así sucesivamente.

Dos preguntas: ¿Romperá efectivamente la memoria caché?

Si. Incluso Stack Overflow usa este método, aunque recuerdo que ellos (con sus millones de visitantes por día y miles de millones de diferentes versiones y configuraciones de cliente y proxy) han tenido algunos casos extremos en los que ni siquiera esto fue suficiente para romper el caché. Pero la suposición general es que esto funcionará y es un método adecuado para romper el almacenamiento en caché en los clientes.

¿El parámetro hará que el navegador nunca almacene en caché la respuesta de esa URL ya que el parámetro indica que se trata de contenido dinámico?

No. El parámetro no cambiará la política de almacenamiento en caché; los encabezados de almacenamiento en caché enviados por el servidor aún se aplican, y si no envía ninguno, los valores predeterminados del navegador.

Es más seguro poner el número de versión en el nombre del archivo real. Esto permite que existan varias versiones a la vez para que pueda implementar una nueva versión y, si aún existen páginas HTML almacenadas en caché que solicitan la versión anterior, obtendrán la versión que funciona con su HTML.

Tenga en cuenta que en una de las implementaciones con versiones más grandes de Internet, jQuery usa números de versión en el nombre de archivo real y permite de manera segura que coexistan múltiples versiones sin ninguna lógica especial del lado del servidor (cada versión es solo un archivo diferente).

Esto rompe el caché una vez cuando implementa nuevas páginas y nuevos archivos vinculados (que es lo que desea) y, a partir de ese momento, esas versiones se pueden almacenar en caché de manera efectiva (lo que también desea).

Como han dicho otros, la destrucción de caché con un parámetro de consulta generalmente se considera una mala idea (tm) y lo ha sido durante mucho tiempo. Es mejor reflejar la versión en el nombre del archivo. Html5 Boilerplate recomienda no usar la cadena de consulta, entre otros.

Dicho esto, de las recomendaciones que he visto que citaban una fuente, todas parecen tomar su sabiduría de un artículo de 2008 de Steve Souders. Sus conclusiones se basan en el comportamiento de los apoderados en ese momento, y pueden ser relevantes o no en estos días. Aún así, en ausencia de información más actual, cambiar el nombre del archivo es la opción segura.

Romperá la caché una vez, después de que el cliente haya descargado el recurso, todas las demás respuestas se entregarán desde la caché del cliente a menos que:

1. se actualiza el parámetro v.
2. el cliente borra su caché

En general, esto debería estar bien, pero es posible que esto no funcione si hay una caché intermedia (un proxy) que está configurada para ignorar los parámetros de la solicitud.

Por ejemplo, si está sirviendo contenido estático a través de Akamai CDN, se puede configurar para ignorar los parámetros de solicitud y evitar la rotura de la memoria caché con este método.

Depende en gran medida de lo robusto que desee que sea su almacenamiento en caché. Por ejemplo, el servidor proxy squid (y posiblemente otros) por defecto a no almacenar en caché URL servido con una cadena de consulta - al menos, lo hizo cuando ese artículo fue escrito. Si no le importan ciertos casos de uso que causan pérdidas de caché innecesarias, continúe con los parámetros de consulta. Pero es muy fácil configurar un esquema de eliminación de caché basado en el nombre de archivo que evita este problema.

Encontré una comparación de las 2 técnicas (cadena de consulta vs nombre de archivo) aquí :

La versión como cadena de consulta tiene dos problemas.

En primer lugar, puede que no siempre sea un navegador que implemente el almacenamiento en caché a través del cual necesitamos pasar. Se dice que ciertos proxies (posiblemente más antiguos) ignoran la cadena de consulta con respecto a su comportamiento de almacenamiento en caché.

En segundo lugar, en ciertos escenarios de implementación más complejos, donde tiene múltiples servidores frontend y / o backend, una actualización es cualquier cosa menos instantánea. Debe poder servir tanto la versión antigua como la nueva de sus activos al mismo tiempo. Vea, por ejemplo, cómo le afecta esto al utilizar Google App Engine.

Otro enfoque similar es usar htaccess mod_rewrite para ignorar parte de la ruta al entregar los archivos. Su página de índice nunca almacenada en caché hace referencia a la ruta más reciente a los archivos.

Desde una perspectiva de desarrollo, es tan fácil como usar parámetros para el número de versión, pero es tan robusto como el enfoque del nombre de archivo.

Use la parte ignorada de la ruta para el número de versión, y el servidor simplemente lo ignorará y entregará el archivo sin caché.

1.2.3/css/styles.csssirve el mismo archivo que css/styles.cssdesde que el primer directorio es eliminado e ignorado por el archivo htaccess

Incluyendo archivos versionados

<?php
  $version = "1.2.3";
?>

<html>
  <head>
    <meta http-equiv="cache-control" content="max-age=0" />
    <meta http-equiv="cache-control" content="no-cache" />
    <meta http-equiv="expires" content="0" />
    <meta http-equiv="expires" content="Tue, 01 Jan 1980 1:00:00 GMT" />
    <meta http-equiv="pragma" content="no-cache" />
    <link rel="stylesheet" type="text/css" href="<?php echo $version ?>/css/styles.css">
  </head>
  <body>
    <script src="<?php echo $version ?>/js/main.js"></script>
  </body>
</html>

Tenga en cuenta que este enfoque significa que debe deshabilitar el almacenamiento en caché de su página de índice: ¿ usa etiquetas <meta> para desactivar el almacenamiento en caché en todos los navegadores?

archivo .htaccess

RewriteEngine On

# if you're requesting a file that exists, do nothing
RewriteCond %{REQUEST_FILENAME} !-f 
# likewise if a directory that exists, do nothing
RewriteCond %{REQUEST_FILENAME} !-d 

# otherwise, rewrite foo/bar/baz to bar/baz - ignore the first directory
RewriteRule ^[^/]+/(.+)$ $1 [L] 

Puede adoptar el mismo enfoque en cualquier plataforma de servidor que permita la reescritura de URL

(condición de reescritura adaptada de mod_rewrite - reescribir el directorio en la cadena de consulta excepto / #! / )

... y si necesita eliminar la memoria caché para su página de índice / punto de entrada del sitio, siempre puede usar JavaSript para actualizarlo.

<script type="text/javascript">
// front end cache bust

var cacheBust = ['js/StrUtil.js', 'js/protos.common.js', 'js/conf.js', 'bootstrap_ECP/js/init.js'];   
for (i=0; i < cacheBust.length; i++){
     var el = document.createElement('script');
     el.src = cacheBust[i]+"?v=" + Math.random();
     document.getElementsByTagName('head')[0].appendChild(el);
}
</script> 

 <script>
    var storedSrcElements = [
         "js/exampleFile.js",
         "js/sampleFile.js",
         "css/style.css"
          ];

    var head= document.getElementsByTagName('head')[0];
    var script;
    var link;
    var versionNumberNew = 4.6;

    for(i=0;i<storedSrcElements.length;i++){
     script= document.createElement('script');
     script.type= 'text/javascript';
     script.src= storedSrcElements[i] + "?" + versionNumberNew;
     head.appendChild(script);
    }     


     </script> 


       ### Change the version number  (versionNumberNew) when you want the new files to be loaded  ###

Espero que esto te ayude a inyectar un archivo JS externo

<script type="text/javascript"> 
var cachebuster = Math.round(new Date().getTime() / 1000); 
document.write('<scr'+'ipt type="text/javascript" src="external.js?cb=' +cachebuster+'"></scr' + 'ipt>');
</script>

Fuente: código Cachebuster en JavaScript