¿Cuáles son las mejores prácticas para evitar CSS obsoletos y JavaScript?

Question

Estoy investigando esto para un proyecto y me pregunto qué están haciendo otras personas para evitar que los archivos CSS y JavaScript obsoletos se publiquen en cada nueva versión. No quiero agregar una marca de tiempo o algo similar que pueda evitar el almacenamiento en caché en cada solicitud.

Estoy trabajando con el framework Spring 2.5 MVC y ya estoy usando las API de Google para servir prototipos y scriptaculous. También estoy considerando usar Amazon S3 y la nueva oferta de Cloudfront para minimizar la latencia de la red.

Answer 1

agrego un parámetro a la solicitud con el número de revisión, algo así como:

<script type="text/javascript" src="/path/to/script.js?ver=456"></script> 

el parámetro 'ver' se actualiza automáticamente con cada generación (leer archivo, que se actualiza la construcción). Esto asegura que los scripts estén en caché solo para la revisión actual.

Answer 2

Utilizar una petición conditional get con un encabezado If-Modified-Since

Answer 3

Esto es realmente un problema muy difícil, y es algo que puede pasar un tiempo ingeniería de la solución correcta para.

Yo recomendaría la publicación de los archivos mediante una marca de tiempo y/o la versión integrada en la URL, por lo que en lugar de:

/media/js/my.js se termina con:

/media/js/v12/my.js o algo similar.

Puede automatizar el control de versiones/marcas de tiempo con cualquier herramienta.

Esto tiene el beneficio adicional de NO romper el sitio a medida que despliega nuevas versiones, y le permite realizar pruebas reales paralelas (a diferencia de una regla de reescritura que simplemente quita la versión y envía el archivo más reciente).

Una cosa a tener en cuenta con JS o CSS es cuando incluyes las URL dependientes dentro de ellas (imágenes de fondo, etc.) necesitas asegurarte de que la marca/fecha JS/CSS cambie si un recurso dentro sí (también como reescribirlos, pero eso es posible con un regex muy simple y un manifiesto de recursos).

No importa lo que hagas, asegúrate de no lanzar un vblah al final, ya que básicamente estás arrojando caché por la ventana cuando lo haces (lo cual es desafortunado, ya que es la forma más sencilla de manejar esto)

Answer 4

Si obtiene el "tiempo modificado" del archivo como una marca de tiempo, se almacenará en caché hasta que se modifique el archivo. Simplemente use una función auxiliar (o lo que se llame en otros marcos) para agregar etiquetas script/css/image que obtengan la marca de tiempo del archivo. En un sistema tipo Unix (que la mayoría de las personas que pasan), simplemente puede touch los archivos para forzar el tiempo modificado para cambiar si es necesario.

Ruby on Rails utiliza esta estrategia en el modo de producción (de forma predeterminada I beleave), y utiliza una marca de tiempo normal en modo de desarrollo (para estar realmente seguro de que algo no está en caché).

Answer 5

Con respecto a los archivos almacenados en caché, todavía tengo que encontrarme con problemas relacionados con los archivos obsoletos almacenados en caché utilizando el método querystring.

Sin embargo, en cuanto a rendimiento, y haciéndose eco de Todd B 's mención de revoluciones por nombre de archivo, por favor, echa un vistazo a Steve Souders' trabajo para más información sobre el tema:

", un proxy populares calamar, no lo hace almacenar en caché los recursos con una cadena de consulta. Esto perjudica el rendimiento cuando varios usuarios detrás de un caché de proxy solicitan el mismo archivo, en lugar de utilizar la versión almacenada en caché, todos deberían enviar una solicitud al servidor de origen ".

"administradores de proxy puede cambiar la configuración para apoyar los recursos de almacenamiento en caché con una cadena de consulta, cuando las cabeceras de caché indican que es apropiado. Sin embargo, la configuración por defecto es lo que los desarrolladores web deben esperar encontrarse con más frecuencia."

http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/

Answer 6

Al igual que @ Eran-Galperin, utilizo un parámetro en la referencia al archivo JS, pero incluyen una referencia generado por el servidor de "última modificación" fecha del archivo. @ stein-g-strindhaug sugiere este enfoque. Se vería algo como esto:

<script type="text/javascript" src="/path/to/script.js?1347486578"></script> 

El servidor ignora el parámetro para el archivo estático y el cliente puede almacenar en caché el guión hasta que cambie el código de la fecha. Si (y solo si) modifica el archivo JS en el servidor, el código de fecha cambiará automáticamente.

Por ejemplo, en PHP, mi guión para crear esta código es el siguiente:

function cachePreventCode($filename) { 
    if (!file_exists($filename)) 
     return ""; 
    $mtime = filemtime($filename); 
    return $mtime; 
} 

Así que cuando el archivo PHP incluye una referencia a un archivo CSS, que podría tener este aspecto:

<link rel="stylesheet" type="text/css" href="main.css?<?= cachePreventCode("main.css") ?>" /> 

... que creará ...

<link rel="stylesheet" type="text/css" href="main.css?1347489244" /> 

Answer 7

Si utiliza Maven, puede utilizar esto, añade que el p om.xml:

<properties> 
    <maven.build.timestamp.format>yyyyMMddHHmm</maven.build.timestamp.format> 
    <timestamp>${maven.build.timestamp}</timestamp> 
</properties> 

Con esto puede acceder a $ {timestamp} en su vista. gusta esta muestra:

<script type="text/javascript" src="/js/myScript.js?t=${timestamp}"></script>