El problema es que está cambiando archivos estáticos, pero no sus nombres de archivo.

Por defecto, apache/nginx/etc sirve contenido estático con encabezados que dicen "almacenar esto en caché durante mucho tiempo" porque es contenido estático , ¿por qué no?

Agregar basura aleatoria a la URL como lo está haciendo con su JS es una chapuza que rompe permanentemente todo el almacenamiento en caché y garantiza que los usuarios descarguen repetidamente exactamente el mismo archivo estático cada vez que soliciten una página. Puede hacer que la basura sea menos aleatoria para romper el caché con menos frecuencia, pero sigue siendo una chapuza ineficiente. [Aunque uno popular, para mi inmensa molestia.]

Idealmente, para paquetes de recursos como JS y CSS, cree un nuevo archivo de paquete de recursos cada vez que lo cambie, por ejemplo: somefile-v1234.js o somefile-20211007.js y actualice la referencia en su fuente HTML. Esto tiene el beneficio adicional de garantizar que las versiones de sus paquetes de recursos siempre coincidan.

Lo mismo ocurre con cualquier otro archivo estático: imágenes, CSV, etc.

El problema que tiene ahora es que actualizó algunas páginas HTML y la única forma de romper el caché es hacer que el usuario realice una acción, como presionar CTRL+F5 para forzar una actualización.

Hay un par de formas de evitar esto:

1. Cambie la configuración de Apache/Nginx/etc para establecer vencimientos más cortos para los encabezados de caché de archivos estáticos. Es posible que pueda apuntar a archivos específicos como index.html , pero YMMV.
2. Sirve el contenido con PHP. Cualquier cosa que se sirva a través de un script PHP no tendrá encabezados de caché establecidos de forma predeterminada, ya que se supone que la salida de un script es dinámica. También puede emitir los encabezados de almacenamiento en caché usted mismo en PHP para controlar qué se almacena en caché durante cuánto tiempo.

Por último, no puede resolver este problema de forma retroactiva. Si un usuario tiene una versión en caché de la página HTML que aún no ha caducado, el usuario DEBE tomar medidas para romper ese caché. No hay nada que se pueda hacer del lado del servidor porque el caché válido le dice al cliente que no tiene que preguntarle al servidor.

Una vez que llega al punto en que su aplicación es lo suficientemente popular como para justificar la colocación de un CDN, este problema empeora mucho , ya que ahora hay un caché en el medio del cual el usuario no tiene control, y es potencialmente un problema costoso . porque algunos proveedores de CDN cobran una tarifa por forzar invalidaciones de caché de CDN.