Contact Form 7 jest zainstalowany na ponad 5 milionach stron. Przez lata działa bez niespodzianek: instalujesz, konfigurujesz, zapominasz. Wystarczy jednak włączyć buforowanie, a w raportach PageSpeed Insights pojawia się uporczywy wiersz: /wp-json/contact-form-7/v1/contact-forms/<id>/refill. Strona nie pada, wizualnie wszystko jest czyste, po prostu pomarańczowy wskaźnik szybkości, który psuje obraz.

Winowajcą nie jest sam plugin, lecz mechanika refill. Gdy CF7 widzi stałą WP_CACHE w pliku wp-config.php, uruchamia AJAX-owe odświeżanie CAPTCHA i elementów dynamicznych, co jest logiczne dla zbuforowanej strony. Problem w tym, że refill odpytuje serwer globalnie. Nawet na stronach, gdzie formularza nie ma i nigdy nie było.

Poprawka, punktowa korekta jednego pliku, controller.php. Trzy linijki, pięć minut i żądania refill znikają z raportów. Sposób działa na wszystkich aktualnych wersjach Contact Form 7 (włącznie z 6.1.6, maj 2026) oraz WordPress od 6.0 do 7.0.

💡 Szybki przegląd:

• Otwierasz plik controller.php w folderze pluginu
• Znajdujesz blok ze sprawdzeniem WP_CACHE, trzy linijki
• Zakomentowujesz je lub usuwasz
• Zapisujesz plik i resetujesz cache na wszystkich poziomach

Co robi refill i dlaczego przeszkadza w szybkości

Gdy w pliku wp-config.php zdefiniowana jest stała define('WP_CACHE', true), Contact Form 7 traktuje każdą stronę jako zbuforowaną. Logika dewelopera jest przejrzysta: statyczny HTML nie odświeża CAPTCHA sam z siebie, potrzebny jest endpoint AJAX, który pobierze świeży kod weryfikacyjny. Refill jest właśnie takim endpointem.

Działa on jednak bez oglądania się na kontekst. Żądania do /wp-json/contact-form-7/v1/contact-forms/<id>/refill są wysyłane ze wszystkich stron pod rząd: strona główna, blog, archiwum, cokolwiek. Na słabym hostingu lub projekcie z przyzwoitym ruchem dziesiątki zbędnych wywołań REST przy każdym odsłonie odczuwalnie obniżają czas ładowania. GTmetrix i PageSpeed Insights podświetlają refill jako zasób blokujący renderowanie.

I co najbardziej podstępne: wizualnie strona działa. Po prostu dostajesz „żółty" wynik szybkości i nie od razu rozumiesz, gdzie szukać przyczyny. Konsola przeglądarki milczy, błędów nie ma, tylko liczby w raporcie.

Wideo: co jeszcze można zrobić ze skryptami Contact Form 7

Krótkie anglojęzyczne wideo pokazuje alternatywne podejście, warunkowe ładowanie skryptów i stylów CF7. Techniki z nagrania doskonale łączą się z naszą poprawką (omówimy to dalej).

Poprawka krok po kroku: wyłączamy refill w controller.php

Krok 1. Dostań się do pliku

Ścieżka do pliku wewnątrz folderu pluginu:

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

Dwa sposoby, by się tam dostać. Przez panel hostingu: menedżer plików w cPanel (File Manager) lub odpowiedniku, rozwiń drzewo folderów według ścieżki powyżej. Przez FTP: połącz się klientem takim jak FileZilla i przejdź do katalogu strony.

Krok 2. Znajdź blok z WP_CACHE

Otwórz plik controller.php w dowolnym edytorze tekstowym. Znajdź trzy linijki:

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

Mechanika jest prosta: jeśli stała WP_CACHE jest zdefiniowana i aktywna, plugin ustawia flagę cached = 1. Od tej flagi startuje kaskada żądań refill. Zgodnie z kodem źródłowym Contact Form 7, w wersji 6.1.6 (maj 2026) blok znajduje się w tym samym miejscu i nie zmienił się, przez całą historię gałęzi 6.x ani razu go nie ruszano.

Krok 3. Zakomentuj lub usuń

Bezpieczniej jest zakomentować. Wstaw // na początku każdej linijki:

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

Dlaczego komentowanie, a nie usuwanie: przy następnej aktualizacji pluginu plik controller.php zostanie nadpisany i poprawka zniknie. Zakomentowany blok rozpoznasz od razu: otworzyłeś plik, zobaczyłeś //, przypomniałeś sobie. Usunięcie działa nie gorzej, ale po miesiącu czy dwóch łatwo zapomnieć, co dokładnie się wycięło. Zapisz plik.

Krok 4. Zresetuj cache i sprawdź ponownie

Po poprawce koniecznie wyczyść cache na wszystkich poziomach:

• Cache pluginów: WP Rocket → Dashboard → Clear Cache; W3 Total Cache → Performance → Purge All Caches; LiteSpeed Cache → LiteSpeed Cache → Purge All; FlyingPress → FlyingPress → Clear Cache.
• Cache serwerowy: jeśli hosting utrzymuje Varnish, Nginx FastCGI lub serwerowy LiteSpeed LSCache, przycisk resetu w panelu hostingu.
• CDN: Cloudflare lub QUIC.cloud → Purge Everything.

Teraz uruchom ponowny test w PageSpeed Insights lub GTmetrix. Otwieraj w trybie incognito, cache przeglądarki może pokazać starą wersję raportu.

Błąd z /wp-json/contact-form-7/v1/contact-forms/<id>/refill powinien zniknąć z sekcji „Eliminate render-blocking resources" lub „Reduce unused JavaScript". Jeśli pozostał, sprawdź plik controller.php (być może poprawka się nie zapisała) oraz cache obiektowy (Redis/Object Cache czasem trzyma starą wersję pliku w pamięci).

Co trzeba wiedzieć po poprawce

Poprawka nie jest wieczna. Każda aktualizacja Contact Form 7 nadpisuje plik controller.php i trzy linijki wracają. Po aktualizacji otwórz plik, upewnij się, że blok jest znów aktywny i zakomentuj go ponownie. Minuta pracy, ale łatwo zapomnieć, trzymaj checklistę.

CAPTCHA może przestać działać. Refill został pierwotnie wymyślony z myślą o CAPTCHA na zbuforowanych stronach. Jeśli używasz wbudowanej CAPTCHA Contact Form 7 (nie Google reCAPTCHA), po wyłączeniu refill kod weryfikacyjny przestanie się odświeżać i formularz nie zostanie wysłany. Dwa wyjścia: przełączyć się na Google reCAPTCHA v3, która działa przez osobne API i nie zależy od refill; albo nie komentować pliku controller.php, tylko skonfigurować warunkowe ładowanie zasobów CF7 przez filtry (o tym poniżej). Sprawdziłeś po poprawce, formularz wysyła się normalnie? Świetnie, zapomnij o sprawie.

Alternatywne podejście, filtry wpcf7_load_js i wpcf7_load_css. Nie wyłączają one refill, ale zabraniają Contact Form 7 ładować skrypty i style na stronach bez formularza. Dodaj w pliku functions.php motywu:

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

A na stronie z formularzem, wewnątrz hooka wp_head, przywróć flagi na true. Usuwa to zbędne zasoby zewsząd, oprócz stron z formularzem. Połącz z wyłączeniem refill przez controller.php, a uzyskasz maksimum wydajności.

⁉️🤔 Często zadawane pytania

Czy koniecznie trzeba edytować controller.php, jeśli nie używam CAPTCHA?

Tak, koniecznie. Żądania refill do /wp-json/contact-form-7/v1/contact-forms/<id>/refill są wysyłane przy każdym cyklu AJAX niezależnie od ustawień CAPTCHA. Wizualnie ich nie zauważasz, ale GTmetrix i Query Monitor rejestrują zbędne wywołania REST API. Po zakomentowaniu trzech linijek endpoint przestaje odpowiadać i szybkość rośnie.

Dlaczego po prostu nie wyłączyć WP_CACHE w wp-config.php?

Stała WP_CACHE to sygnał dla całego ekosystemu WordPress, że strony można buforować. WP Rocket, W3 Total Cache, FlyingPress i inne pluginy są od niej zależne. Usuwając WP_CACHE, zniszczysz buforowanie całkowicie, a spadek szybkości będzie znacznie bardziej odczuwalny niż jedno żądanie refill. Właściwa droga: zostawić buforowanie, ale wyciąć jego efekt uboczny w CF7.

Czy poprawka zadziała na multisite?

Zadziała, ale plik wp-content/plugins/contact-form-7/includes/controller.php jest wspólny dla całej sieci. Poprawka dotknie wszystkich podstron jednocześnie. Przed zmianą sprawdź, czy na innych stronach sieci są formularze z wbudowaną CAPTCHA Contact Form 7. Jeśli tak, przetestuj wysyłkę na każdej po poprawce lub rozważ filtr-wyjątek zamiast globalnej poprawki.

Czy można zautomatyzować przywracanie poprawki po aktualizacji pluginu?

W dokumentacji Contact Form 7 nie ma gotowego filtra do podmiany akurat tych trzech linijek. W praktyce checklista „po aktualizacji CF7 → sprawdź controller.php" jest pewniejsza niż jakikolwiek własnoręcznie napisany mu-plugin. Plik zmienia się rzadko, przez całą gałąź 6.x blok WP_CACHE nie był ani razu edytowany.

Formularz przestał się wysyłać po poprawce, co robić?

Najpierw sprawdź typ CAPTCHA: Contact Form 7 → Integracja. Wbudowana CAPTCHA pluginu (nie reCAPTCHA) zależy od refill przy zmianie kodu weryfikacyjnego. Przełącz się na Google reCAPTCHA v3, działa ona przez własne API i nie jest powiązana z refill. Druga droga: cofnij poprawkę w controller.php, zostaw refill włączony i skonfiguruj warunkowe ładowanie zasobów CF7 tylko na stronach z formularzami przez wpcf7_load_js i wpcf7_load_css.

Contact Form 7 i buforowanie: co robić w 2026 roku

Poprawka w controller.php to mikrochirurgia, która usuwa jedyne wąskie gardło (bottleneck) pluginu. Minuta czasu, żadnych dodatkowych pluginów, działa na WordPress od 6.0 do 7.0 oraz wszystkich aktualnych wydaniach Contact Form 7.

Jeśli chcesz wycisnąć maksimum, połącz: wyłącz refill przez controller.php i skonfiguruj warunkowe ładowanie zasobów przez filtry wpcf7_load_js i wpcf7_load_css. Pierwsze usuwa żądania refill, drugie nie pozwala skryptom formularza wisieć na stronach bez formularza. Razem całkowicie usuwają Contact Form 7 z raportów PageSpeed Insights jako źródło problemów.

🔗 Contact Form 7 na WordPress.org