Crawling de diciembre: almacenamiento en caché HTTP

Lunes, 9 de diciembre de 2024

Permítanos almacenar en caché, por favor.

A medida que Internet creció a lo largo de los años, también lo hizo la cantidad de rastreo de Google. Si bien la infraestructura de rastreo de Google admite mecanismos de almacenamiento en caché heurístico, de hecho siempre lo ha hecho, la cantidad de solicitudes que se pueden devolver desde cachés locales ha disminuido: hace 10 años, alrededor del 0,026% del total de las recuperaciones eran almacenables en caché, lo cual ya no es tan impresionante; hoy esa cifra es del 0,017%.

¿Por qué es importante el almacenamiento en caché?

El almacenamiento en caché es una pieza fundamental del gran rompecabezas que es Internet. El almacenamiento en caché permite que las páginas se carguen a la velocidad del rayo en las visitas recurrentes, ahorra recursos informáticos y, por lo tanto, también recursos naturales, y ahorra una enorme cantidad de ancho de banda costoso tanto para los clientes como para los servidores.

Especialmente si tiene un sitio grande con contenido que cambia raramente bajo URL individuales, permitir el almacenamiento en caché localmente puede ayudar a que su sitio sea rastreado de manera más eficiente. La infraestructura de rastreo de Google admite el almacenamiento en caché HTTP heurístico tal como lo define el
estándar de almacenamiento en caché HTTP, específicamente a través del ETag de respuesta y el If-None-Match encabezado de solicitud, y el Last-Modified de respuesta y el If-Modified-Since encabezado de solicitud.

Recomendamos encarecidamente usar ETag porque es menos propenso a errores y equivocaciones (el valor no está estructurado a diferencia del valor Last-Modified ). Y, si tiene la opción, configúrelos ambos: Internet se lo agradecerá. Tal vez.

En cuanto a lo que usted considera un cambio que requiere que los clientes actualicen sus cachés, eso depende de usted. Nuestra recomendación es que requiera una actualización de caché ante cambios significativos en su contenido; si solo actualizó la fecha de derechos de autor en la parte inferior de su página, probablemente eso no sea significativo.

ETag y If-None-Match

Los rastreadores de Google admiten ETag basado en solicitudes condicionales exactamente como se define en el
estándar de almacenamiento en caché HTTP. Es decir, para indicar la preferencia de almacenamiento en caché a los rastreadores de Google, establezca el valor Etag en cualquier cadena ASCII arbitraria (generalmente un hash del contenido o número de versión, pero también podría ser un trozo de π, depende de usted) único para la representación del contenido alojado por la URL accedida. Por ejemplo, si aloja diferentes versiones del mismo contenido bajo la misma URL (digamos, versión móvil y de escritorio), cada versión podría tener su propio valor ETag único.

Los rastreadores de Google que admiten el almacenamiento en caché enviarán el valor ETag devuelto para un rastreo anterior de esa URL en el If-None-Match header. Si el valor ETag
enviado por el rastreador coincide con el valor actual que generó el servidor, su servidor debería devolver un código de estado HTTP 304 (No modificado) sin cuerpo HTTP. Esta última parte, sin cuerpo HTTP, es la parte importante por un par de razones:

• su servidor no tiene que gastar recursos informáticos en generar contenido realmente; es decir, ahorra dinero
• su servidor no tiene que transferir el cuerpo HTTP; es decir, ahorra dinero

En el lado del cliente, como el navegador de un usuario o Googlebot, el contenido bajo esa URL se recupera de la caché interna del cliente. Debido a que no hay transferencia de datos involucrada, esto sucede a la velocidad del rayo, lo que hace felices a los usuarios y potencialmente ahorra algunos recursos para ellos también.

Last-Modified y If-Modified-Since

De manera similar a ETag, los rastreadores de Google también admiten Last-Modified based
solicitudes condicionales, exactamente como se define en el estándar de almacenamiento en caché HTTP. Esto funciona de la misma manera que ETag desde una perspectiva semántica (se utiliza un identificador para decidir si el recurso es almacenable en caché) y proporciona los mismos beneficios que ETag en el lado de los clientes.

Solo tenemos un par de recomendaciones si está utilizando Last-Modified como directiva de almacenamiento en caché:

1. La fecha en el Last-Modified encabezado debe estar formateada de acuerdo con el
   estándar HTTP. Para evitar problemas de análisis, recomendamos utilizar el siguiente formato de fecha: “Día de la semana, DD Mon YYYY HH:MM:SSZona horaria”. Por ejemplo,“.
2. ” Fri, 4 Sep 1998 19:15:56 GMT Aunque no es obligatorio, considere también establecer el campo
   max-age del encabezado Cache-Control para ayudar a los rastreadores a determinar cuándo volver a rastrear la URL específica. Establezca el valor del campo.

max-age

en la cantidad esperada de segundos que el contenido permanecerá sin cambios. Por ejemplo, Cache-Control: max-age=94043/If-None-Match y uno para
Last-Modified/If-Modified-Since — para visualizar cómo se supone que debe funcionar:

Si te dedicas a hacer felices a tus usuarios y quizás también quieres ahorrarte unos cuantos dólares en tu factura de hosting, habla con tu proveedor de hosting o CMS, o con tus desarrolladores sobre cómo habilitar el almacenamiento en caché HTTP para tu sitio. Como mínimo, tus usuarios te apreciarán un poco más.

Si quieres charlar sobre el almacenamiento en caché, dirígete a tu
comunidad de ayuda de Search Centralmás cercana, y si tienes comentarios sobre cómo estamos almacenando en caché, deja tus comentarios en
la documentación sobre el almacenamiento en caché
que publicamos junto con esta entrada de blog.

Publicado por Gary Illyes

¿Quieres aprender más sobre el rastreo? Consulta toda la serie Crawling December: