¿Hay alguna manera de poner algún código en mi página para que cuando alguien visite un sitio, borre la memoria caché del navegador, para que pueda ver los cambios?
Lenguajes utilizados: ASP.NET, VB.NET y, por supuesto, HTML, CSS y jQuery.
¿Hay alguna manera de poner algún código en mi página para que cuando alguien visite un sitio, borre la memoria caché del navegador, para que pueda ver los cambios?
Lenguajes utilizados: ASP.NET, VB.NET y, por supuesto, HTML, CSS y jQuery.
Respuestas:
Si esto se trata .css
y .js
cambia, una forma es "reventar la memoria caché" agregando algo como " _versionNo
" al nombre del archivo para cada versión. Por ejemplo:
script_1.0.css // This is the URL for release 1.0
script_1.1.css // This is the URL for release 1.1
script_1.2.css // etc.
O bien, hágalo después del nombre del archivo:
script.css?v=1.0 // This is the URL for release 1.0
script.css?v=1.1 // This is the URL for release 1.1
script.css?v=1.2 // etc.
Puede consultar este enlace para ver cómo podría funcionar.
script.js?v=1.2
. (O si no realiza un seguimiento de las versiones, simplemente use el archivo con la última hora de modificación, que es aún más fácil de hacer). ¡No estoy seguro si eso es lo que quiso decir el comentarista anterior!
<link />
etiquetas dinámicamente e inyectar la versión de la aplicación como un parámetro de cadena de consulta. Alternativamente, algunos CMS tendrán una "versión de recursos del cliente" como una configuración para todo el CMS que se adjunta: el administrador del sitio puede aumentar manualmente esa versión nr, y las actualizaciones del CMS también podrían actualizarla automáticamente. En pocas palabras: debe representar las URL del archivo dinámicamente.
Mire en el control de caché y vence la etiqueta META.
<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">
<META HTTP-EQUIV="EXPIRES" CONTENT="Mon, 22 Jul 2002 11:12:01 GMT">
Otra práctica común es agregar cadenas que cambian constantemente al final de los archivos solicitados. Por ejemplo:
<script type="text/javascript" src="main.js?v=12392823"></script>
Esta es una pregunta antigua, pero creo que necesita una respuesta más actualizada porque ahora hay una manera de tener más control sobre el almacenamiento en caché del sitio web.
En Offline Web Applications (que es realmente cualquier sitio web HTML5) applicationCache.swapCache()
puede usarse para actualizar la versión en caché de su sitio web sin la necesidad de volver a cargar la página manualmente.
Este es un ejemplo de código de la Guía para principiantes sobre el uso de la caché de aplicaciones en HTML5 Rocks que explica cómo actualizar a los usuarios a la versión más reciente de su sitio:
// Check if a new cache is available on page load.
window.addEventListener('load', function(e) {
window.applicationCache.addEventListener('updateready', function(e) {
if (window.applicationCache.status == window.applicationCache.UPDATEREADY) {
// Browser downloaded a new app cache.
// Swap it in and reload the page to get the new hotness.
window.applicationCache.swapCache();
if (confirm('A new version of this site is available. Load it?')) {
window.location.reload();
}
} else {
// Manifest didn't changed. Nothing new to server.
}
}, false);
}, false);
Consulte también Uso del caché de la aplicación en Mozilla Developer Network para obtener más información.
Las cosas cambian rápidamente en la Web. Esta pregunta se hizo en 2009 y en 2012 publiqué una actualización sobre una nueva forma de manejar el problema descrito en la pregunta. Pasaron otros 4 años y ahora parece que ya está en desuso. Gracias a cgaldiolo por señalarlo en los comentarios.
Actualmente, a partir de julio de 2016, el Estándar HTML, Sección 7.9, Aplicaciones web sin conexión incluye una advertencia de desaprobación:
Esta característica está en proceso de ser eliminada de la plataforma web. (Este es un proceso largo que lleva muchos años). En este momento, se desaconseja el uso de cualquiera de las funciones de la aplicación web sin conexión. Use trabajadores de servicio en su lugar.
Lo mismo ocurre con el uso del caché de la aplicación en la red de desarrolladores de Mozilla a la que hice referencia en 2012:
En desuso
Esta característica se ha eliminado de los estándares web. Aunque algunos navegadores aún pueden soportarlo, está en proceso de ser eliminado. No lo use en proyectos viejos o nuevos. Las páginas o aplicaciones web que lo usan pueden romperse en cualquier momento.
Consulte también el error 1204581: agregue un aviso de desaprobación para AppCache si la intercepción de recuperación del trabajador de servicio está habilitada .
No como tal. Un método es enviar los encabezados apropiados al entregar contenido para forzar la recarga del navegador:
Asegurarse de que una página web no esté en caché, en todos los navegadores.
Si busca "cache header"
o algo similar aquí en SO, encontrará ejemplos específicos de ASP.NET.
Otra forma menos limpia, pero a veces solo si no puede controlar los encabezados en el lado del servidor, es agregar un parámetro GET aleatorio al recurso que se llama:
myimage.gif?random=1923849839
Para recursos estáticos, el almacenamiento en caché correcto sería utilizar parámetros de consulta con el valor de cada implementación o versión de archivo. Esto tendrá el efecto de borrar la memoria caché después de cada implementación.
/Content/css/Site.css?version={FileVersionNumber}
Aquí está el ejemplo de ASP.NET MVC.
<link href="@Url.Content("~/Content/Css/Reset.css")?version=@this.GetType().Assembly.GetName().Version" rel="stylesheet" type="text/css" />
No olvides actualizar la versión de ensamblaje.
?version=@ViewContext.Controller.GetType().Assembly.GetName().Version
Tuve un problema similar y así es como lo resolví:
En el index.html
archivo he agregado manifiesto:
<html manifest="cache.manifest">
En la <head>
sección incluye script que actualiza la caché:
<script type="text/javascript" src="update_cache.js"></script>
En la <body>
sección he insertado la función onload:
<body onload="checkForUpdate()">
En cache.manifest
he puesto todos los archivos que quiero almacenar en caché. Es importante ahora que funciona en mi caso (Apache) simplemente actualizando cada vez el comentario de la "versión". También es una opción para nombrar archivos con "? Ver = 001" o algo al final del nombre, pero no es necesario . Cambiar solo # version 1.01
activa el evento de actualización de caché.
CACHE MANIFEST
# version 1.01
style.css
imgs/logo.png
#all other files
Es importante incluir 1., 2. y 3. puntos solo en index.html. De otra manera
GET http://foo.bar/resource.ext net::ERR_FAILED
se produce porque cada archivo "secundario" intenta almacenar en caché la página mientras la página ya está en caché.
En el update_cache.js
archivo he puesto este código:
function checkForUpdate()
{
if (window.applicationCache != undefined && window.applicationCache != null)
{
window.applicationCache.addEventListener('updateready', updateApplication);
}
}
function updateApplication(event)
{
if (window.applicationCache.status != 4) return;
window.applicationCache.removeEventListener('updateready', updateApplication);
window.applicationCache.swapCache();
window.location.reload();
}
Ahora solo cambia los archivos y, en el manifiesto, debe actualizar el comentario de la versión. Ahora, visitar la página index.html actualizará el caché.
Las partes de la solución no son mías, pero las encontré a través de Internet y las reuní para que funcionen.
Tuve un caso en el que tomaría fotos de clientes en línea y necesitaría actualizar el div si se cambia una foto. El navegador todavía mostraba la foto anterior. Así que usé el truco de llamar a una variable GET aleatoria, que sería única cada vez. Aquí está si podría ayudar a alguien
<img src="/photos/userid_73.jpg?random=<?php echo rand() ?>" ...
EDITAR Como lo han señalado otros, seguir es una solución mucho más eficiente ya que volverá a cargar imágenes solo cuando se cambien, identificando este cambio por el tamaño del archivo:
<img src="/photos/userid_73.jpg?modified=<? filemtime("/photos/userid_73.jpg")?>"
Muchas respuestas están perdiendo el punto: la mayoría de los desarrolladores son conscientes de que desactivar el caché es ineficiente. Sin embargo, hay muchas circunstancias comunes en las que la eficiencia no es importante y el comportamiento predeterminado de la memoria caché está muy dañado.
Estos incluyen pruebas de guiones iterativos anidados (¡el más grande!) Y soluciones alternativas de software de terceros. Ninguna de las soluciones dadas aquí es adecuada para abordar tales escenarios comunes. La mayoría de los navegadores web son demasiado agresivos y no proporcionan medios razonables para evitar estos problemas.
<meta http-equiv="pragma" content="no-cache" />
Consulte también /programming/126772/how-to-force-a-web-browser-not-to-cache-images
La actualización de la URL a lo siguiente funciona para mí:
/custom.js?id=1
Al agregar un número único después ?id=
e incrementarlo para nuevos cambios, los usuarios no tienen que presionar CTRL + F5
para actualizar el caché. Alternativamente, puede agregar una versión hash o string de la hora actual o Epoch after?id=
Algo como ?id=1520606295
Aquí está la página MDSN sobre la configuración del almacenamiento en caché en ASP.NET.
Response.Cache.SetExpires(DateTime.Now.AddSeconds(60))
Response.Cache.SetCacheability(HttpCacheability.Public)
Response.Cache.SetValidUntilExpires(False)
Response.Cache.VaryByParams("Category") = True
If Response.Cache.VaryByParams("Category") Then
'...
End If
No estoy seguro de si eso realmente podría ayudarlo, pero así es como el almacenamiento en caché debería funcionar en cualquier navegador. Cuando el navegador solicita un archivo, siempre debe enviar una solicitud al servidor a menos que haya un modo "fuera de línea". El servidor leerá algunos parámetros como la fecha de modificación o etags.
El servidor devolverá una respuesta de error 304 para NO MODIFICADO y el navegador tendrá que usar su caché. Si el etag no se valida en el lado del servidor o la fecha de modificación es inferior a la fecha de modificación actual, el servidor debe devolver el nuevo contenido con la nueva fecha de modificación o etags o ambos.
Si no se envían datos de almacenamiento en caché al navegador, supongo que el comportamiento es indeterminado, el navegador puede o no almacenar archivos que no indican cómo se almacenan en caché. Si configura los parámetros de almacenamiento en caché en la respuesta, almacenará en caché sus archivos correctamente y el servidor puede optar por devolver un error 304 o el nuevo contenido.
Asi es como debería de hacerse. Usar parámetros aleatorios o números de versión en las URL es más como un truco que cualquier otra cosa.
http://www.checkupdown.com/status/E304.html http://en.wikipedia.org/wiki/HTTP_ETag http://www.xpertdeveloper.com/2011/03/last-modified-header-vs- expire-header-vs-etag /
Después de leer, vi que también hay una fecha de caducidad. Si tiene problemas, puede ser que tenga una fecha de caducidad configurada. En otras palabras, cuando el navegador almacenará en caché su archivo, ya que tiene una fecha de caducidad, no debería tener que volver a solicitarlo antes de esa fecha. En otras palabras, nunca solicitará el archivo al servidor y nunca recibirá un 304 no modificado. Simplemente usará el caché hasta que se alcance la fecha de caducidad o se borre el caché.
Supongo que tiene una fecha de caducidad y debe usar etags modificados por última vez o una combinación de todos ellos y asegurarse de que no haya fecha de caducidad.
Si la gente tiende a actualizarse mucho y el archivo no cambia mucho, entonces sería aconsejable establecer una gran fecha de vencimiento.
¡Mis 2 centavos!
Implementé esta solución simple que funciona para mí (aún no en el entorno de producción):
function verificarNovaVersio() {
var sVersio = localStorage['gcf_versio'+ location.pathname] || 'v00.0.0000';
$.ajax({
url: "./versio.txt"
, dataType: 'text'
, cache: false
, contentType: false
, processData: false
, type: 'post'
}).done(function(sVersioFitxer) {
console.log('Versió App: '+ sVersioFitxer +', Versió Caché: '+ sVersio);
if (sVersio < (sVersioFitxer || 'v00.0.0000')) {
localStorage['gcf_versio'+ location.pathname] = sVersioFitxer;
location.reload(true);
}
});
}
Tengo un pequeño archivo ubicado donde están los html:
"versio.txt":
v00.5.0014
Esta función se llama en todas mis páginas, por lo que, al cargarla, comprueba si el valor de la versión de localStorage es inferior a la versión actual y hace un
location.reload(true);
... para forzar la recarga desde el servidor en lugar de la memoria caché.
(obviamente, en lugar de localStorage puede usar cookies u otro almacenamiento persistente del cliente)
Opté por esta solución por su simplicidad, ya que solo mantener un solo archivo "versio.txt" obligará a recargar el sitio completo.
El método queryString es difícil de implementar y también se almacena en caché (si cambia de v1.1 a una versión anterior se cargará desde el caché, entonces significa que el caché no se vacía, manteniendo todas las versiones anteriores en caché).
Soy un poco novato y agradecería su revisión y revisión profesional para garantizar que mi método sea un buen enfoque.
Espero eso ayude.
Además de configurar Cache-control: no-cache, también debe establecer el encabezado Expires en -1 si desea que la copia local se actualice cada vez (algunas versiones de IE parecen requerir esto).
Consulte Caché HTTP: consulte con el servidor y envíe siempre If-Modified-Since
Hay un truco que puede usarse: el truco consiste en agregar un parámetro / cadena al nombre del archivo en la etiqueta del script y cambiarlo cuando el archivo cambia.
<script src="myfile.js?version=1.0.0"></script>
El navegador interpreta la cadena completa como la ruta del archivo aunque lo que viene después del "?" Son parámetros. Entonces, lo que sucede ahora es que la próxima vez que actualice su archivo simplemente cambie el número en la etiqueta del script en su sitio web (Ejemplo <script src="myfile.js?version=1.0.1"></script>
) y cada navegador de usuarios verá que el archivo ha cambiado y obtendrá una nueva copia.
¿Forzar a los navegadores a borrar el caché o recargar los datos correctos? He probado la mayoría de las soluciones descritas en stackoverflow, algo de trabajo, pero después de un tiempo, finalmente almacena en caché y muestra el script o archivo cargado anteriormente. ¿Hay alguna otra forma de borrar el caché (css, js, etc.) y realmente funcione en todos los navegadores?
Descubrí que hasta ahora se pueden recargar recursos específicos individualmente si cambias la fecha y la hora en tus archivos en el servidor. "Borrar caché" no es tan fácil como debería ser. En lugar de borrar el caché en mis navegadores, me di cuenta de que "tocar" los archivos del servidor en caché en realidad cambiará la fecha y la hora del archivo de origen en caché en el servidor (Probado en Edge, Chrome y Firefox) y la mayoría de los navegadores descargarán automáticamente la mayoría copia actual actualizada de lo que está en su servidor (código, gráficos, cualquier multimedia también). Le sugiero que simplemente copie las secuencias de comandos más recientes en el servidor y la solución "haga lo táctil" antes de que se ejecute su programa, por lo que cambiará la fecha de todos sus archivos problemáticos a la fecha y hora más actual, luego descargará una copia nueva a su navegador:
<?php
touch('/www/sample/file1.css');
touch('/www/sample/file2.js');
?>
entonces ... el resto de tu programa ...
Me tomó algo de tiempo resolver este problema (ya que muchos navegadores actúan de manera diferente a los diferentes comandos, pero todos verifican la hora de los archivos y se comparan con la copia descargada en su navegador, si la fecha y la hora son diferentes, se actualizarán), si usted no puede ir por el supuesto camino correcto, siempre hay otra solución utilizable y mejor. Saludos cordiales y feliz campamento. Por cierto toque (); o las alternativas funcionan en muchos lenguajes de programación incluidos en javascript bash sh php y puede incluirlos o llamarlos en html.
¿Desea borrar el caché o simplemente asegurarse de que su página actual (¿cambiada?) No esté en caché?
Si es lo último, debería ser tan simple como
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">