Los ETag son una alternativa (pero se pueden usar en combinación con) "Último tiempo modificado" para determinar la validación de la memoria caché.
El cliente puede enviar una precondición como if-coincide o if-none-coincide según la ETag. Esto no es solo para las solicitudes GET (que es lo que hace webpagetest.org), puede usar "actualización oportunista" para que una solicitud PUT tenga una condición previa y no realice la operación de actualización si el recurso se ha actualizado desde que ETag se actualizó última adquirida.
En pocas palabras: presiona editar en una página en su CMS, su amigo presiona editar en una página en su CMS, su amigo realiza su edición y presiona guardar y finalmente presiona guardar, sin un encabezado ETag o Content-MD5 HTTP que necesitaría para reinventar la rueda para evitar que ocurran problemas (como limpiar los cambios de tus amigos), la solución ya es parte del protocolo HTTP y, por lo tanto, tiene sentido usarlo.
En general, estoy de acuerdo con AOL (que ejecuta webpagetest.org) en su consejo de "talla única": es mejor no obstruir los encabezados HTTP con cadenas crípticas (los ETags generalmente no son bonitos o legibles para humanos) cuando hay un segundo de diferencia ( que Last-Modified-Time puede detectar) lo hará para el trabajo en cuestión.
Si una página se actualiza varias veces por segundo y necesita absolutamente que se muestre la última versión más precisa, puede experimentar con otras soluciones que no sean HTTP GET o simplemente usar ETags.
Tenga cuidado de que sus ETags no incluyan información por sistema de archivos, por cambio de configuración del servidor, etc. (como inodos, que es el valor predeterminado en Apache); de lo contrario, tendrá problemas cuando haya dos servidores (los ETag de cada uno no coincidirán).