ESQUIVANDO LA CACHÉ DEL NAVEGADOR
La memoria caché del navegador es un gran invento:
-Cada vez que navegas por un contenido nuevo, que antes no habías visitado, el navegador lo descarga del servidor y lo visualiza, pero además guarda dicho contenido en el disco duro local, para su uso posterior.
-Cuando navegas la segunda vez por una página o tienes que descargar otra vez la misma imagen o el mismo fichero, si está guardado en la caché, el navegador no hace una petición al servidor, sino que carga y visualiza el contenido localmente guardado.
Este invento viene muy bien porque así se ahorra tráfico en internet. La cuestión es si eso interesa a los usuarios o no. A los programadores no, ya lo anticipo.
En particular venía muy bien cuando teníamos conexiones a internet lentas, via módem 56Kbps o similares, y las páginas que descargábamos pertenecían a eso que se ha dado en llamar WEB 1.0, páginas de contenidos estáticos sobre todo.
Pero ahora ya no tenemos conexiones lentas, y la web que navegamos es WEB 2.0, donde las páginas son e incluyen contenidos dinámicos, que pueden cambiar en cualquier momento.
La dirección de las páginas no cambia, pero sí sus contenidos. El navegador sabe que un contenido ha sido visitado gracias a su dirección de descarga. Pero nada sabe sobre si dicho contenido ha cambiado en el servidor desde la última descarga.
Para más asombro, el botón de recargar de los navegadores no se salta la caché como cualquier usuario pensaría intuitivamente que debería hacer.
Para recargar saltándose la caché hay que usar el teclado. Las combinaciones de teclas
CTRL+R
ó
CTRL+F5
suelen ser las que usan los navegadores para este fin.
Este método funciona bien para la recarga de la página principal.
La petición síncrona de la página principal sí que se produce esquivando la caché.
Eso incluye el código PHP, ASP, JSP o cualquier código que se ejecute en el servidor.
Pero ¿QUÉ PASA CON LAS PETICIONES ASÍNCRONAS?
Eso incluye el código javascript principal, pero no aquellos objetos que son cargados asíncronamente a través de direcciones estáticas.
Eso incluye la animación flash swf principal, pero no aquellas secundarias o hijas cargadas por ésta, que son llamadas a través de una dirección estática. Tampoco incluye aquellos contenidos descargados asíncronamente mediante el método .load() o similares
Eso incluye el applet java principal, pero no los objetos que son cargados asíncronamente por él usando direcciones de descarga estáticas.
¿Cuál es el problema?
Desde luego no es culpa del lenguaje o plataforma de desarrollo.
Tampoco es culpa de los navegadores, aunque bien es cierto que algunos facilitan más que otros el borrado de la caché o son configurables para que la caché se borre automáticamente al cerrar el programa.
¿Cuál es el gran problema de la caché de los navegadores que tenemos que esquivar los programadores?
Pues cuando lo que se visualiza es el resultado de peticiones asíncronas de contenidos cuya dirección de descarga no cambia pero que resultan ser contenidos que cambian dinámicamente.
Por ejemplo una foto que es accedida asíncronamente, vía AJAX, AS3,... por
http:// www.rojasdelgado.com/foto.jpg
que resulte que cambie dinámicamente. El navegador que tenga caché siempre cargará desde la caché.
Eso fuerza a los programadores a cambiar la direccion de descarga de manera aleatoria, pero manteniendo el objetivo de descarga. Si queremos, por ejemplo, descargar asíncronamente esa foto mediante un pseudocódigo como
url="http:// www.rojasdelgado.com/foto.jpg";
downloader.load(url);
generamos una url dinámica pegándole, por ejemplo, la hora del sistema:
url="http:// www.rojasdelgado.com/foto.jpg";
fecha=new date();
url=url+"?"+fecha.formato("DDMMAAHHmmSS").toString();
downloader.load(url);
De este modo la url que se solicita es siempre distinta, por ejemplo:
http:// www.rojasdelgado.com/foto.jpg?24022013135922
o
http:// www.rojasdelgado.com/foto.jpg?24022013135925
si se realiza la descarga 3 segundos después.
Así que, repito, la caché de los navegadores es un gran invento, y añado, que dá muchos quebraderos de cabeza a los programadores.
Y al monosílabo le pongo tilde cuando no debería llevarla para que vds. sepan que cuando dá es que dá.
-Cada vez que navegas por un contenido nuevo, que antes no habías visitado, el navegador lo descarga del servidor y lo visualiza, pero además guarda dicho contenido en el disco duro local, para su uso posterior.
-Cuando navegas la segunda vez por una página o tienes que descargar otra vez la misma imagen o el mismo fichero, si está guardado en la caché, el navegador no hace una petición al servidor, sino que carga y visualiza el contenido localmente guardado.
Este invento viene muy bien porque así se ahorra tráfico en internet. La cuestión es si eso interesa a los usuarios o no. A los programadores no, ya lo anticipo.
En particular venía muy bien cuando teníamos conexiones a internet lentas, via módem 56Kbps o similares, y las páginas que descargábamos pertenecían a eso que se ha dado en llamar WEB 1.0, páginas de contenidos estáticos sobre todo.
Pero ahora ya no tenemos conexiones lentas, y la web que navegamos es WEB 2.0, donde las páginas son e incluyen contenidos dinámicos, que pueden cambiar en cualquier momento.
La dirección de las páginas no cambia, pero sí sus contenidos. El navegador sabe que un contenido ha sido visitado gracias a su dirección de descarga. Pero nada sabe sobre si dicho contenido ha cambiado en el servidor desde la última descarga.
Para más asombro, el botón de recargar de los navegadores no se salta la caché como cualquier usuario pensaría intuitivamente que debería hacer.
Para recargar saltándose la caché hay que usar el teclado. Las combinaciones de teclas
CTRL+R
ó
CTRL+F5
suelen ser las que usan los navegadores para este fin.
Este método funciona bien para la recarga de la página principal.
La petición síncrona de la página principal sí que se produce esquivando la caché.
Eso incluye el código PHP, ASP, JSP o cualquier código que se ejecute en el servidor.
Pero ¿QUÉ PASA CON LAS PETICIONES ASÍNCRONAS?
Eso incluye el código javascript principal, pero no aquellos objetos que son cargados asíncronamente a través de direcciones estáticas.
Eso incluye la animación flash swf principal, pero no aquellas secundarias o hijas cargadas por ésta, que son llamadas a través de una dirección estática. Tampoco incluye aquellos contenidos descargados asíncronamente mediante el método .load() o similares
Eso incluye el applet java principal, pero no los objetos que son cargados asíncronamente por él usando direcciones de descarga estáticas.
¿Cuál es el problema?
Desde luego no es culpa del lenguaje o plataforma de desarrollo.
Tampoco es culpa de los navegadores, aunque bien es cierto que algunos facilitan más que otros el borrado de la caché o son configurables para que la caché se borre automáticamente al cerrar el programa.
¿Cuál es el gran problema de la caché de los navegadores que tenemos que esquivar los programadores?
Pues cuando lo que se visualiza es el resultado de peticiones asíncronas de contenidos cuya dirección de descarga no cambia pero que resultan ser contenidos que cambian dinámicamente.
Por ejemplo una foto que es accedida asíncronamente, vía AJAX, AS3,... por
http:// www.rojasdelgado.com/foto.jpg
que resulte que cambie dinámicamente. El navegador que tenga caché siempre cargará desde la caché.
Eso fuerza a los programadores a cambiar la direccion de descarga de manera aleatoria, pero manteniendo el objetivo de descarga. Si queremos, por ejemplo, descargar asíncronamente esa foto mediante un pseudocódigo como
url="http:// www.rojasdelgado.com/foto.jpg";
downloader.load(url);
generamos una url dinámica pegándole, por ejemplo, la hora del sistema:
url="http:// www.rojasdelgado.com/foto.jpg";
fecha=new date();
url=url+"?"+fecha.formato("DDMMAAHHmmSS").toString();
downloader.load(url);
De este modo la url que se solicita es siempre distinta, por ejemplo:
http:// www.rojasdelgado.com/foto.jpg?24022013135922
o
http:// www.rojasdelgado.com/foto.jpg?24022013135925
si se realiza la descarga 3 segundos después.
Así que, repito, la caché de los navegadores es un gran invento, y añado, que dá muchos quebraderos de cabeza a los programadores.
Y al monosílabo le pongo tilde cuando no debería llevarla para que vds. sepan que cuando dá es que dá.