WPO Drupal: No mates las caches!!!

El otro día me tocó investigar cómo mejorar el rendimiento de una web Drupal que no va lo suficientemente rápida y que tiene problemas con las caches.

Esta web tiene varias cosas a mejorar, pero de la que me vengo a quejar hoy es de un módulo custom con un código equivalente a:

/**
 * Implements hook_views_pre_render().
 */
function my_module_views_pre_render(ViewExecutable $view) {
  \Drupal::service('page_cache_kill_switch')->trigger();
}

Para quien no lo sepa, al usar la clase KillSwitch, podemos activar la eliminación de la memoria caché de la página en determinadas circunstancias. Y esta clase se encuentra en el servicio page_cache_kill_switch, por lo que podemos llamar a su método trigger() si lo que queremos es limpiar la caché de la página actual.

El problema es que en este caso en concreto se estaba lanzando esa limpieza en el hook_views_pre_render, sin ningún tipo de filtro. Ni por nombre de views, ni url de página ni nada de nada.

Por tanto, de forma resumida, hay un módulo custom que tiene un código que desactiva/invalida/elimina la cache de página en cualquier pagina que tenga una views. ¡Y en esta web más del 90% de las páginas tienen al menos 1 views!

Es casi lo mismo que haber desactivado el módulo page_cache (el cual seguía activo).

Esto me recuerda otro caso de otro cliente que también tenía unos problemas similares. En ese caso eran 3 módulos que sumados daban problemas. Basicamente tenia el módulo webform + el captcha (que invalida las caches de las páginas donde hay formularios) + el quicklink (precarga las urls visibles). El problema era que en todas las páginas se estaba precargando la página de contacto con su correspondiente captcha, el cual invalidaba la cache.

Realmente lo que está mal no es eliminar la cache, es eliminarla de la mayoría de páginas, no darte cuenta del problema que eso conlleva y luego quejarse de que Drupal es lento. Y esto se nota cuando tu web es mediana/grande y tienes miles de visitas diarias.