🐛 Contact Form 7 - corrigiendo el problema de caché de relleno

Contact Form 7 funciona en más de 5 millones de sitios. Funciona durante años sin sorpresas: instale, configure, olvídese. Pero active el caché y los informes de PageSpeed Insights empezarán a mostrar una línea persistente: /wp-json/contact-form-7/v1/contact-forms/<id>/refill. El sitio no se cae, visualmente todo se ve limpio, solo un indicador naranja de velocidad que arruina la imagen.

El culpable no es el plugin en sí, sino el mecanismo de refill. Cuando CF7 detecta WP_CACHE en wp-config.php, activa actualizaciones AJAX para el CAPTCHA y los elementos dinámicos, lo cual tiene sentido para páginas en caché. El problema es que el refill golpea al servidor de forma global. Incluso en páginas donde no hay ningún formulario.

La solución es una edición quirúrgica de un archivo, controller.php. Tres líneas, cinco minutos y las solicitudes de refill desaparecen de los informes. El método funciona en todas las versiones actuales de Contact Form 7 (incluida la 6.1.6, mayo de 2026) y en WordPress desde la 6.0 hasta la 7.0.

💡 Resumen rápido:

• Abra el archivo controller.php en la carpeta del plugin
• Encuentre el bloque con la comprobación de WP_CACHE, tres líneas
• Coméntelas o elimínelas
• Guarde el archivo y limpie la caché en todos los niveles

Qué hace el refill y por qué perjudica la velocidad

Cuando la constante define('WP_CACHE', true) está establecida en wp-config.php, Contact Form 7 trata cada página como si estuviera en caché. La lógica del desarrollador es transparente: el HTML estático no actualiza el CAPTCHA por sí solo, necesita un endpoint AJAX que obtenga un código de verificación nuevo. El refill es exactamente ese endpoint.

Pero funciona sin tener en cuenta el contexto. Las solicitudes a /wp-json/contact-form-7/v1/contact-forms/<id>/refill se envían desde todas las páginas en serie: la página de inicio, el blog, los archivos, cualquier cosa. En un hosting débil o en un proyecto con tráfico decente, docenas de llamadas REST innecesarias por cada vista de página ralentizan notablemente el tiempo de carga. GTmetrix y PageSpeed Insights señalan el refill como un recurso que bloquea el renderizado.

Y la parte más insidiosa: visualmente el sitio funciona. Usted simplemente obtiene una puntuación de velocidad «amarilla» y no entiende de inmediato dónde buscar. La consola del navegador está en silencio, no hay errores, solo números en el informe.

Vídeo: qué más puede hacer con los scripts de Contact Form 7

Este breve vídeo en inglés muestra un enfoque alternativo, la carga condicional de los scripts y estilos de CF7. Las técnicas del vídeo se combinan perfectamente con nuestra solución (lo cubriremos más abajo).

Solución paso a paso: desactivar el refill en controller.php

Paso 1. Acceda al archivo

Ruta al archivo dentro de la carpeta del plugin:

1
wp-content/plugins/contact-form-7/includes/controller.php

Dos formas de llegar. A través del panel de hosting: administrador de archivos en cPanel (File Manager) o equivalente, expanda el árbol de carpetas siguiendo la ruta anterior. Por FTP: conéctese con un cliente como FileZilla y navegue hasta el directorio del sitio.

Paso 2. Encuentre el bloque WP_CACHE

Abra controller.php en cualquier editor de texto. Encuentre tres líneas:

1
if ( defined( 'WP_CACHE' ) && WP_CACHE ) {
2
    $wpcf7['cached'] = 1;
3
}

La mecánica es simple: si WP_CACHE está definido y activo, el plugin establece la bandera cached = 1. Esta bandera desencadena una cascada de solicitudes de refill. Según el código fuente de Contact Form 7, en la versión 6.1.6 (mayo de 2026) el bloque está en el mismo lugar y no ha cambiado; en toda la historia de la rama 6.x no se ha tocado ni una sola vez.

Paso 3. Comente o elimine

Es más seguro comentar. Ponga // al principio de cada línea:

1
// if ( defined( 'WP_CACHE' ) && WP_CACHE ) {
2
//     $wpcf7['cached'] = 1;
3
// }

Por qué comentar en lugar de eliminar: en la próxima actualización del plugin, controller.php se sobrescribirá y la edición se perderá. Usted reconocerá el bloque comentado de inmediato: abrió el archivo, vio //, recordó. La eliminación funciona igual de bien, pero en uno o dos meses es fácil olvidar qué fue exactamente lo que cortó. Guarde el archivo.

Paso 4. Limpie la caché y vuelva a comprobar

Después de la edición, asegúrese de limpiar la caché en todos los niveles:

• Caché del plugin: WP Rocket → Dashboard → Clear Cache; W3 Total Cache → Performance → Purge All Caches; LiteSpeed Cache → LiteSpeed Cache → Purge All; FlyingPress → FlyingPress → Clear Cache.
• Caché del servidor: si el host ejecuta Varnish, Nginx FastCGI o LiteSpeed LSCache a nivel de servidor, hay un botón de limpieza en el panel de hosting.
• CDN: Cloudflare o QUIC.cloud → Purge Everything.

Ahora ejecute una prueba repetida en PageSpeed Insights o GTmetrix. Abra en modo incógnito, la caché del navegador podría mostrar la versión antigua del informe.

El error con /wp-json/contact-form-7/v1/contact-forms/<id>/refill debería desaparecer de la sección «Eliminar recursos que bloquean el renderizado» o «Reducir JavaScript no utilizado». ¿Sigue ahí? Compruebe controller.php (puede que la edición no se haya guardado) y la caché de objetos (Redis/Object Cache a veces mantiene la versión antigua del archivo en memoria).

Lo que necesita saber después de la solución

La edición no es permanente. Cada actualización de Contact Form 7 sobrescribe controller.php y las tres líneas vuelven. Después de una actualización, abra el archivo, asegúrese de que el bloque está activo de nuevo y coméntelo otra vez. Un minuto de trabajo, pero fácil de olvidar, tenga una lista de comprobación.

El CAPTCHA podría romperse. El refill se diseñó originalmente para el CAPTCHA en páginas en caché. Si utiliza el CAPTCHA integrado de Contact Form 7 (no Google reCAPTCHA), después de desactivar el refill el código de verificación dejará de actualizarse y el formulario no se enviará. Dos soluciones: cambie a Google reCAPTCHA v3, que funciona a través de una API separada y no depende del refill; o no comente controller.php, sino configure la carga condicional de los assets de CF7 mediante filtros (más sobre esto abajo). ¿Probó después de la edición y el formulario se envía con normalidad? Perfecto, olvídese del tema.

Enfoque alternativo, filtros wpcf7_load_js y wpcf7_load_css. No desactivan el refill, pero evitan que Contact Form 7 cargue scripts y estilos en páginas sin formulario. Añada al functions.php del tema:

1
add_filter( 'wpcf7_load_js', '__return_false' );
2
add_filter( 'wpcf7_load_css', '__return_false' );

Y en la página con el formulario, dentro del hook wp_head, devuelva las banderas a true. Esto elimina los assets innecesarios de todas partes excepto de las páginas con formularios. Combine con la desactivación del refill a través de controller.php para obtener el máximo rendimiento.

⁉️🤔 Preguntas frecuentes

¿Es obligatorio editar controller.php si no uso CAPTCHA?

Sí, es obligatorio. Las solicitudes de refill a /wp-json/contact-form-7/v1/contact-forms/<id>/refill se envían en cada ciclo AJAX independientemente de la configuración del CAPTCHA. Visualmente no las nota, pero GTmetrix y Query Monitor registran llamadas innecesarias a la API REST. Después de comentar las tres líneas, el endpoint deja de responder y la velocidad aumenta.

¿Por qué no simplemente desactivar WP_CACHE en wp-config.php?

La constante WP_CACHE es una señal para todo el ecosistema de WordPress de que las páginas pueden almacenarse en caché. WP Rocket, W3 Total Cache, FlyingPress y otros plugins dependen de ella. Al eliminar WP_CACHE, destruirá el caché por completo; la caída de velocidad será mucho más notable que una solicitud de refill. La forma correcta: mantenga el caché, pero elimine su efecto secundario en CF7.

¿La solución funciona en multisitio?

Funcionará, pero wp-content/plugins/contact-form-7/includes/controller.php se comparte en toda la red. La edición afectará a todos los sitios secundarios simultáneamente. Antes de hacer cambios, compruebe si otros sitios de la red tienen formularios con el CAPTCHA integrado de Contact Form 7. Si es así, pruebe el envío en cada uno después de la edición o considere una excepción mediante filtro en lugar de una edición global.

¿Se puede automatizar la reaplicación de la edición tras una actualización del plugin?

La documentación de Contact Form 7 no tiene un filtro ya preparado para reemplazar exactamente estas tres líneas. En la práctica, una lista de comprobación «después de actualizar CF7 → revisar controller.php» es más fiable que cualquier mu-plugin personalizado. El archivo cambia raramente; a lo largo de toda la rama 6.x, el bloque WP_CACHE no se ha editado ni una sola vez.

El formulario dejó de enviarse después de la edición, ¿qué hago?

Primero compruebe el tipo de CAPTCHA: Contact Form 7 → Integración. El CAPTCHA integrado del plugin (no reCAPTCHA) depende del refill para cambiar el código de verificación. Cambie a Google reCAPTCHA v3, que funciona a través de su propia API y no está vinculado al refill. Segunda opción: revierta la edición de controller.php, deje el refill activado y configure la carga condicional de los assets de CF7 solo en las páginas con formularios mediante wpcf7_load_js y wpcf7_load_css.

Contact Form 7 y caché: qué hacer en 2026

Editar controller.php es una microcirugía que elimina el único cuello de botella estrecho del plugin. Un minuto de tiempo, sin plugins adicionales, funciona en WordPress desde la 6.0 hasta la 7.0 y en todas las compilaciones actuales de Contact Form 7.

¿Quiere exprimir el máximo? Combine: desactive el refill mediante controller.php y configure la carga condicional de assets mediante los filtros wpcf7_load_js y wpcf7_load_css. Lo primero elimina las solicitudes de refill, lo segundo evita que los scripts del formulario se carguen en páginas sin formulario. Juntos, sacan a Contact Form 7 de los informes de PageSpeed Insights como fuente de problemas, por completo.

🔗 Contact Form 7 en WordPress.org