Contact Form 7 körs på över 5 miljoner sajter. Det fungerar år efter år utan överraskningar: installera, konfigurera, glöm. Men slå på caching, så börjar PageSpeed Insights-rapporterna visa en återkommande rad: /wp-json/contact-form-7/v1/contact-forms/<id>/refill. Sajten kraschar inte, allt ser rent ut visuellt, bara en orange hastighetsindikator som förstör bilden.

Boven är inte själva tillägget, utan refill-mekanismen. När CF7 ser WP_CACHE i wp-config.php triggar det AJAX-uppdateringar för CAPTCHA och dynamiska element, vilket är logiskt för cachade sidor. Problemet är att refill anropar servern globalt. Även på sidor där det inte finns något formulär alls.

Lösningen är en kirurgisk redigering av en fil, controller.php. Tre rader, fem minuter, och refill-anropen försvinner från rapporterna. Metoden fungerar på alla aktuella versioner av Contact Form 7 (inklusive 6.1.6, maj 2026) och WordPress från 6.0 till 7.0.

💡 Snabb översikt:

• Öppna filen controller.php i tilläggets mapp
• Hitta blocket med WP_CACHE-kontrollen, tre rader
• Kommentera bort dem eller radera dem
• Spara filen och rensa cache på alla nivåer

Vad refill gör och varför det skadar hastigheten

När konstanten define('WP_CACHE', true) är satt i wp-config.php behandlar Contact Form 7 varje sida som cachad. Utvecklarens logik är tydlig: statisk HTML uppdaterar inte CAPTCHA av sig själv, du behöver en AJAX-endpoint som hämtar en ny verifieringskod. Refill är exakt den endpointen.

Men den fungerar utan hänsyn till sammanhanget. Anrop till /wp-json/contact-form-7/v1/contact-forms/<id>/refill skickas från alla sidor i rad: startsida, blogg, arkiv, allt. På svag hosting eller ett projekt med hyfsad trafik saktar dussintals onödiga REST-anrop per sidvisning märkbart ner laddningstiden. GTmetrix och PageSpeed Insights markerar refill som en resurs som blockerar renderingen.

Och det mest lömska: visuellt fungerar sajten. Du får bara ett "gult" hastighetsbetyg och förstår inte omedelbart var du ska gräva. Webbläsarkonsolen är tyst, inga fel, bara siffror i rapporten.

Video: vad mer du kan göra med Contact Form 7-skript

Den här korta engelskspråkiga videon visar ett alternativt tillvägagångssätt, villkorlig inläsning av CF7-skript och stilmallar. Teknikerna från videon kombineras perfekt med vår fix (vi tar upp det nedan).

Steg-för-steg-fix: inaktivera refill i controller.php

Steg 1. Hitta filen

Sökväg till filen inuti tilläggets mapp:

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

Två sätt att komma dit. Via webbhotellets panel: filhanteraren i cPanel (File Manager) eller motsvarande, expandera mappträdet enligt sökvägen ovan. Via FTP: anslut med en klient som FileZilla och navigera till sajtens katalog.

Steg 2. Hitta WP_CACHE-blocket

Öppna controller.php i valfri textredigerare. Hitta tre rader:

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

Mekaniken är enkel: om WP_CACHE är definierad och aktiv sätter tillägget flaggan cached = 1. Denna flagga utlöser en kaskad av refill-anrop. Enligt Contact Form 7s källkod ligger blocket i version 6.1.6 (maj 2026) på samma plats och har inte ändrats, genom hela 6.x-grenens historia har det inte rörts en enda gång.

Steg 3. Kommentera bort eller radera

Det är säkrare att kommentera. Sätt // i början av varje rad:

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

Varför kommentera istället för att radera: vid nästa uppdatering av tillägget skrivs controller.php över, och redigeringen försvinner. Du känner igen det kommenterade blocket omedelbart: öppnade filen, såg //, kom ihåg. Radering fungerar lika bra, men om en månad eller två är det lätt att glömma exakt vad du klippte bort. Spara filen.

Steg 4. Rensa cache och kontrollera igen

Efter redigeringen, se till att rensa cache på alla nivåer:

• Tilläggscache: WP Rocket → Dashboard → Clear Cache; W3 Total Cache → Performance → Purge All Caches; LiteSpeed Cache → LiteSpeed Cache → Purge All; FlyingPress → FlyingPress → Clear Cache.
• Servercache: om webbhotellet kör Varnish, Nginx FastCGI eller LSCache på servernivå finns en rensningsknapp i webbhotellets panel.
• CDN: Cloudflare eller QUIC.cloud → Purge Everything.

Kör nu ett nytt test i PageSpeed Insights eller GTmetrix. Öppna i inkognitoläge, webbläsarens cache kan visa den gamla versionen av rapporten.

Felet med /wp-json/contact-form-7/v1/contact-forms/<id>/refill bör försvinna från sektionen "Eliminate render-blocking resources" eller "Reduce unused JavaScript". Finns det kvar? Kontrollera controller.php (redigeringen kanske inte sparades) och objektcache (Redis/Object Cache behåller ibland den gamla filversionen i minnet).

Vad du behöver veta efter fixen

Redigeringen är inte permanent. Varje uppdatering av Contact Form 7 skriver över controller.php, och de tre raderna kommer tillbaka. Efter en uppdatering, öppna filen, kontrollera att blocket är aktivt igen och kommentera bort det på nytt. En minuts arbete, men lätt att glömma, ha en checklista.

CAPTCHA kan sluta fungera. Refill var ursprungligen utformat för CAPTCHA på cachade sidor. Om du använder Contact Form 7s inbyggda CAPTCHA (inte Google reCAPTCHA) kommer verifieringskoden att sluta uppdateras efter att refill inaktiverats, och formuläret kommer inte att skickas. Två lösningar: byt till Google reCAPTCHA v3, det fungerar via ett separat API och är inte beroende av refill; eller kommentera inte bort i controller.php, utan ställ in villkorlig inläsning av CF7-tillgångar via filter (mer om detta nedan). Testat efter redigeringen, formuläret skickas normalt? Toppen, glöm det.

Alternativt tillvägagångssätt, filtren wpcf7_load_js och wpcf7_load_css. De inaktiverar inte refill, men förhindrar Contact Form 7 från att ladda skript och stilmallar på sidor utan formulär. Lägg till i temats functions.php:

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

Och på sidan med formuläret, inuti wp_head-hooken, sätt tillbaka flaggorna till true. Detta tar bort onödiga tillgångar från alla sidor utom de med formulär. Kombinera med att inaktivera refill via controller.php för att få maximal prestanda.

⁉️🤔 Vanliga frågor

Är det obligatoriskt att redigera controller.php om jag inte använder CAPTCHA?

Ja, obligatoriskt. Refill-anrop till /wp-json/contact-form-7/v1/contact-forms/<id>/refill skickas vid varje AJAX-cykel oavsett CAPTCHA-inställningar. Visuellt märker du dem inte, men GTmetrix och Query Monitor registrerar onödiga REST API-anrop. Efter att ha kommenterat bort de tre raderna slutar endpointen att svara, och hastigheten ökar.

Varför inte bara inaktivera WP_CACHE i wp-config.php?

Konstanten WP_CACHE är en signal för hela WordPress-ekosystemet att sidor kan cachas. WP Rocket, W3 Total Cache, FlyingPress och andra tillägg förlitar sig på den. Tar du bort WP_CACHE förstör du cachningen helt, hastighetsfallet blir mycket mer märkbart än ett enda refill-anrop. Rätt sätt: behåll cachningen, men skär bort dess bieffekt i CF7.

Fungerar fixen på multisite?

Den fungerar, men wp-content/plugins/contact-form-7/includes/controller.php delas över hela nätverket. Redigeringen påverkar alla undersajter samtidigt. Innan du gör ändringar, kontrollera om andra sajter i nätverket har formulär med Contact Form 7s inbyggda CAPTCHA. Om ja, testa inskickning på var och en efter redigeringen, eller överväg ett filterundantag istället för en global redigering.

Kan man automatisera återställandet av redigeringen efter en tilläggsuppdatering?

Contact Form 7s dokumentation har inget färdigt filter för att ersätta exakt dessa tre rader. I praktiken är en checklista "efter CF7-uppdatering → kontrollera controller.php" mer tillförlitlig än något anpassat mu-plugin. Filen ändras sällan, genom hela 6.x-grenen har WP_CACHE-blocket inte redigerats en enda gång.

Formuläret slutade skickas efter redigeringen, vad gör jag?

Kontrollera först CAPTCHA-typen: Contact Form 7 → Integration. Tilläggets inbyggda CAPTCHA (inte reCAPTCHA) är beroende av refill för att ändra verifieringskoden. Byt till Google reCAPTCHA v3, det fungerar via sitt eget API och är inte kopplat till refill. Andra alternativet: återställ redigeringen i controller.php, lämna refill aktiverat och ställ in villkorlig inläsning av CF7-tillgångar endast på sidor med formulär via wpcf7_load_js och wpcf7_load_css.

Contact Form 7 och caching: vad du ska göra 2026

Att redigera controller.php är mikrokirurgi som tar bort tilläggets enda smala flaskhals. En minuts tid, inga ytterligare tillägg, fungerar på WordPress från 6.0 till 7.0 och alla aktuella Contact Form 7-byggen.

Vill du pressa ut maximalt? Kombinera: inaktivera refill via controller.php och ställ in villkorlig inläsning av tillgångar via filtren wpcf7_load_js och wpcf7_load_css. Det första tar bort refill-anrop, det andra förhindrar att formulärskript hänger kvar på sidor utan formulär. Tillsammans tar de bort Contact Form 7 från PageSpeed Insights-rapporter som en källa till problem, helt och hållet.

🔗 Contact Form 7 på WordPress.org