Lunes, 9 de diciembre del 2024
Déjanos usar la memoria caché.
A medida que Internet ha ido creciendo a lo largo de los años, también lo ha hecho el número de rastreos de Google. Aunque la infraestructura de rastreo de Google admite mecanismos de almacenamiento en caché heurísticos (de hecho, siempre los ha admitido), el número de solicitudes que se pueden devolver desde las cachés locales ha disminuido: hace 10 años, aproximadamente el 0,026 % del total de las búsquedas se podía almacenar en caché, lo cual ya no es tan impresionante; hoy en día, ese número es del 0,017 %.
¿Por qué es importante el almacenamiento en caché?
El almacenamiento en caché es una parte fundamental del gran rompecabezas que es Internet. El almacenamiento en caché permite que las páginas se carguen a una velocidad increíble cuando se vuelven a visitar. Además, ahorra recursos informáticos y, por tanto, también recursos naturales, y ahorra una gran cantidad de ancho de banda, que es muy caro, tanto para los clientes como para los servidores.
Si tienes un sitio grande con contenido que rara vez cambia en URLs concretas, permitir el almacenamiento en caché local puede ayudar a que tu sitio se rastree de forma más eficiente. La infraestructura de rastreo de Google admite el almacenamiento en caché heurístico de HTTP, tal como se define en el estándar de almacenamiento en caché de HTTP, concretamente a través del encabezado de respuesta ETag y el encabezado de solicitud If-None-Match, y del encabezado de respuesta Last-Modified y el encabezado de solicitud If-Modified-Since.
Te recomendamos que uses ETag porque es menos propenso a errores (a diferencia de Last-Modified, el valor no está estructurado). Si tienes la opción, configúralos ambos: Internet te lo agradecerá. Tal vez.
En cuanto a lo que consideras un cambio que requiera que los clientes actualicen sus cachés, eso depende de ti. Te recomendamos que actualices la caché cuando hagas cambios significativos en tu contenido. Si solo has actualizado la fecha de los derechos de autor que aparece en la parte inferior de la página, probablemente no sea un cambio significativo.
ETag y If-None-Match
Los rastreadores de Google admiten solicitudes condicionales basadas en ETag tal como se definen en el estándar de almacenamiento en caché HTTP.
Es decir, para indicar la preferencia de almacenamiento en caché a los rastreadores de Google, asigne el valor Etag a cualquier cadena ASCII arbitraria (normalmente un hash del contenido o el número de versión, pero también podría ser una parte de π, depende de ti) única para la representación del contenido alojado en la URL a la que se accede.
Por ejemplo, si alojas diferentes versiones del mismo contenido bajo la misma URL (por ejemplo, una versión para móviles y una para ordenadores), cada versión podría tener su propio valor ETag único.
Los rastreadores de Google que admitan el almacenamiento en caché enviarán el valor ETag devuelto en un rastreo anterior de esa URL en If-None-Match header. Si el valor de ETag enviado por el rastreador coincide con el valor actual generado por el servidor, el servidor debe devolver un código de estado HTTP 304 (No modificado) sin cuerpo HTTP. Esta última parte, sin cuerpo de HTTP, es importante por varios motivos:
- Tu servidor no tiene que gastar recursos de computación en generar contenido, lo que significa que ahorras dinero.
- Tu servidor no tiene que transferir el cuerpo HTTP, es decir, ahorras dinero.
En el lado del cliente, como el navegador de un usuario o el robot de Google, el contenido de esa URL se obtiene de la caché interna del cliente. Como no hay transferencia de datos, el proceso es muy rápido, lo que hace felices a los usuarios y, posiblemente, también les ahorra recursos.
Last-Modified y If-Modified-Since
Al igual que ETag, los rastreadores de Google admiten las solicitudes condicionales Last-Modified based, tal como se define en el estándar de almacenamiento en caché de HTTP. Desde un punto de vista semántico, funciona de la misma forma que ETag (se usa un identificador para decidir si el recurso se puede almacenar en caché) y ofrece las mismas ventajas que ETag en el lado de los clientes.
Si usas Last-Modified como una directiva de almacenamiento en caché, te recomendamos lo siguiente:
-
La fecha del encabezado
Last-Modifieddebe tener el formato que se indica en el estándar HTTP. Para evitar problemas de análisis, te recomendamos que uses el siguiente formato de fecha: "Día de la semana, DD Mon YYYY HH:MM:SS Zona horaria". Por ejemplo, "Fri, 4 Sep 1998 19:15:56 GMT". -
Aunque no es obligatorio, te recomendamos que también definas el campo
max-agedel encabezadoCache-Controlpara ayudar a los rastreadores a determinar cuándo volver a rastrear la URL específica. Asigna al campomax-ageel número de segundos que se espera que el contenido permanezca sin cambios. Por ejemplo,Cache-Control: max-age=94043.
Ejemplos
Si eres como yo, te resultará difícil entender cómo funciona el almacenamiento en caché heurístico. Sin embargo, creo que te resultará útil ver un ejemplo de la cadena de solicitudes y respuestas. Aquí tienes dos cadenas, una para ETag/If-None-Match y otra para Last-Modified/If-Modified-Since, para que veas cómo se supone que funciona:
ETag/If-None-Match |
Last-Modified/If-Modified-Since |
|
|---|---|---|
Respuesta de un servidor a un rastreo: esta es la respuesta de la que un rastreador puede guardar los campos del encabezado de precondición ETag y Last-Modified.
|
HTTP/1.1 200 OK Content-Type: text/plain Date: Fri, 4 Sep 1998 19:15:50 GMT ETag: "34aa387-d-1568eb00" ... |
HTTP/1.1 200 OK Content-Type: text/plain Date: Fri, 4 Sep 1998 19:15:50 GMT Last-Modified: Fri, 4 Sep 1998 19:15:56 GMT Cache-Control: max-age=94043 ... |
Solicitud condicional del rastreador posterior: la solicitud condicional se basa en los valores del encabezado de la precondición guardados en una solicitud anterior. Los valores se envían de nuevo al servidor para que se validen en los encabezados de solicitud If-None-Match y If-Modified-Since.
|
GET /hello.world HTTP/1.1 Host: www.example.com Accept-Language: en, hu User-Agent: Googlebot/2.1 (+http://www.google.com/bot.html) If-None-Match: "34aa387-d-1568eb00" ... |
GET /hello.world HTTP/1.1 Host: www.example.com Accept-Language: en, hu User-Agent: Googlebot/2.1 (+http://www.google.com/bot.html) If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT ... |
Respuesta del servidor a la solicitud condicional: dado que los valores de la cabecera de precondición enviados por el rastreador se validan en el servidor, el servidor devuelve un código de estado HTTP 304 (sin un cuerpo HTTP) al rastreador. Esto ocurrirá con todas las solicitudes posteriores hasta que los prerrequisitos no se puedan validar (la fecha de ETag o Last-Modified cambie en el servidor).
|
HTTP/1.1 304 Not Modified Date: Fri, 4 Sep 1998 19:15:50 GMT Expires: Fri, 4 Sep 1998 19:15:52 GMT Vary: Accept-Encoding If-None-Match: "34aa387-d-1568eb00" ... |
HTTP/1.1 304 Not Modified Date: Fri, 4 Sep 1998 19:15:50 GMT Expires: Fri, 4 Sep 1998 19:15:51 GMT Vary: Accept-Encoding If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT ... |
Si quieres que tus usuarios estén satisfechos y, además, quieres ahorrar algo de dinero en tu factura de alojamiento, habla con tu proveedor de alojamiento o de CMS, o con tus desarrolladores, sobre cómo habilitar el almacenamiento en caché HTTP en tu sitio. Al menos, tus usuarios te querrán un poco más.
Si quieres hablar sobre el almacenamiento en caché, dirígete a la comunidad de ayuda del Centro de la Búsqueda más cercana. Si tienes comentarios sobre cómo almacenamos en caché, déjanoslos en la documentación sobre el almacenamiento en caché que hemos publicado junto con esta entrada de blog.