Cómo borrar la caché del navegador en Mac para pruebas de QA: la escalera de reinicio
Cómo borrar la caché del navegador en Mac para pruebas de QA: la escalera de reinicio
Respuesta rápida: Para borrar la caché del navegador en Mac en pruebas de QA, sube por la escalera desde el reinicio más ligero hasta el más pesado: recarga forzada, «Disable cache» en las DevTools, borrado de datos del sitio (cookies, almacenamiento, service workers) y, por último, un perfil desechable nuevo. Vaciar las carpetas de caché del disco solo soluciona archivos obsoletos. No restablece sesiones ni el estado de la aplicación.
Reportas un bug. El desarrollador responde: «En mi máquina funciona». Vuelves a probar y, de pronto, también funciona en la tuya. No ha cambiado nada, salvo que tu navegador ha servido en silencio una copia nueva de un archivo que tenía retenido.
El trabajo de QA en Mac tiene un problema particular con las cachés: necesitas saber exactamente contra qué capa de estado almacenado estás probando. «Borra la caché» es una instrucción demasiado burda para eso. Esta guía divide el estado almacenado del navegador en capas y te da, para cada una, el reinicio más pequeño que funciona.
¿Qué es lo que está atascado? Relaciona el síntoma con la capa
Los navegadores guardan varios tipos de estado, y «la caché» es solo uno de ellos.
Síntoma Capa probable Solución más ligera CSS/JS antiguos tras un despliegue Caché HTTP Recarga forzada Faltan los cambios, pero solo en la ventana normal Caché HTTP o service worker DevTools con la caché desactivada y, después, anular el registro del service worker Sigues conectado con el usuario equivocado Cookies / almacenamiento Borrar los datos del sitio de ese origen Un feature flag o el estado del onboarding no se restablece localStorage / IndexedDB Borrar los datos del sitio La app funciona sin conexión cuando no debería Service worker + Cache Storage Anular el registro del service worker y borrar los datos del sitio El bug no se reproduce en la máquina de un compañero Estado acumulado en el perfil Perfil nuevo
Empieza por arriba de la escalera y baja solo si el problema persiste. Cada peldaño adicional descarta más estado que quizá necesites para reproducir el fallo.
Peldaño 1: recarga forzada (segundos, sin pérdida de datos)
Una recarga forzada omite la caché durante la carga actual de la página.
Chrome, Edge, Firefox: ??R Safari: ??R («Recargar desde el origen»)
Esto resuelve la queja más habitual de «build antiguo». No toca cookies, almacenamiento ni service workers, y solo afecta a esa carga, así que los recursos que se pidan después aún pueden salir de la caché.
Peldaño 2: haz que las DevTools omitan la caché mientras pruebas
Si vas a recargar toda la tarde, deja de hacerlo a mano.
Chrome/Edge: abre las DevTools ? pestaña Network ? marca Disable cache. Solo se aplica mientras las DevTools estén abiertas. Firefox: DevTools ? Red ? Desactivar caché HTTP (con la caja de herramientas abierta). Safari: primero activa el menú Desarrollo (Safari ? Ajustes ? Avanzado ? «Mostrar funciones para desarrolladores web»; el texto varía según la versión) y después usa Desarrollo ? Desactivar cachés.
Chrome tiene además un atajo muy útil: con las DevTools abiertas, haz clic derecho en el botón de recarga y elige «Vaciar caché y volver a cargar de manera forzada».
Una trampa en la que cae mucha gente: «Disable cache» no anula el registro de los service workers. Un service worker puede seguir sirviendo sus propias respuestas almacenadas. Si el peldaño 2 no lo arregla, pasa al 3.
Peldaño 3: borra los datos del sitio de un solo origen
Borrarlo todo rara vez es lo que quieres. Limitar el reinicio al sitio que estás probando conserva tus otras sesiones (y tu cordura).
Chrome/Edge: DevTools ? Application ? Storage ? Clear site data. Antes de pulsar, revisa qué está marcado: cookies, almacenamiento local y de sesión, IndexedDB, Cache Storage y service workers se pueden incluir o excluir por separado. El panel Service Workers también permite anular el registro de un worker directamente y ofrece la opción Update on reload.
Firefox: Ajustes ? Privacidad y seguridad ? Cookies y datos del sitio ? Gestionar datos y elimina el sitio concreto. Como alternativa, usa la pestaña Almacenamiento de las DevTools.
Safari: Ajustes ? Privacidad ? Gestionar datos de sitios web, busca el dominio y elimínalo.
Este es el reinicio adecuado para «conectado con el usuario equivocado», feature flags obsoletos y bugs del modo sin conexión. Es también el peldaño en el que conviene anotar qué has borrado, porque «borré los datos del sitio» y «vacié solo la caché HTTP» pueden dar resultados de prueba distintos.
Peldaño 4: perfil desechable (el reinicio reproducible)
Cuando necesites demostrar que un bug no se debe a tu propio estado acumulado, no friegues el perfil viejo: empieza con uno limpio.
Opciones rápidas:
Una ventana privada/de incógnito (sin estado persistente, pero las extensiones suelen estar desactivadas, lo que altera la prueba). Un perfil temporal de Chrome desde Terminal: ? bash open -na « Google Chrome » –args –user-data-dir=/tmp/qa-profile-01
Cada ruta nueva te da un perfil limpio, sin cookies, sin caché y sin extensiones. Borra la carpeta al terminar o consérvala como línea base con nombre para un plan de pruebas concreto.
Es la respuesta más limpia a «¿es la app o es mi navegador?». Y es la mejor forma de pasar a otra persona unos pasos de reproducción que parten de un estado conocido.
Dónde vive la caché en el disco (y por qué conviene limpiarla)
Todo lo anterior actúa sobre estado que gestiona el propio navegador. Aparte, las carpetas de caché se acumulan en el disco, algo que importa si trabajas todo el día con varios navegadores y builds de prueba. Ubicaciones habituales dentro de tu carpeta Library de usuario:
Chrome: ~/Library/Caches/Google/Chrome/ Edge: ~/Library/Caches/Microsoft Edge/ Firefox: ~/Library/Caches/Firefox/Profiles/