Contact Form 7 kjører på over 5 millioner nettsteder. Det fungerer i årevis uten overraskelser: installer, konfigurer, glem. Men slå på caching, og PageSpeed Insights-rapporter begynner å vise en vedvarende linje: /wp-json/contact-form-7/v1/contact-forms/<id>/refill. Nettstedet krasjer ikke, alt ser rent ut visuelt, bare en oransje hastighetsindikator som ødelegger bildet.

Synderen er ikke selve utvidelsen, men refill-mekanismen. Når CF7 ser WP_CACHE i wp-config.php, utløser det AJAX-oppdateringer for CAPTCHA og dynamiske elementer, noe som gir mening for hurtigbufrede sider. Problemet er at refill treffer serveren globalt. Selv på sider der det ikke finnes noe skjema i det hele tatt.

Løsningen er en kirurgisk redigering av én fil, controller.php. Tre linjer, fem minutter, og refill-forespørsler forsvinner fra rapporter. Metoden fungerer på alle gjeldende Contact Form 7-versjoner (inkludert 6.1.6, mai 2026) og WordPress fra 6.0 til 7.0.

💡 Rask oversikt:

• Åpne filen controller.php i utvidelsesmappen
• Finn blokken med WP_CACHE-sjekk, tre linjer
• Kommenter dem ut eller slett dem
• Lagre filen og tøm hurtigbuffer på alle nivåer

Hva refill gjør og hvorfor det skader hastigheten

Når konstanten define('WP_CACHE', true) er satt i wp-config.php, behandler Contact Form 7 hver side som bufret. Utviklerens logikk er gjennomsiktig: statisk HTML oppdaterer ikke CAPTCHA av seg selv, du trenger et AJAX-endepunkt som henter en fersk verifiseringskode. Refill er nøyaktig det endepunktet.

Men det fungerer uten hensyn til kontekst. Forespørsler til /wp-json/contact-form-7/v1/contact-forms/<id>/refill går ut fra alle sider på rad: hjemmeside, blogg, arkiv, hva som helst. På svak hosting eller et prosjekt med anstendig trafikk, bremser dusinvis av unødvendige REST-kall per sidevisning lastetiden merkbart. GTmetrix og PageSpeed Insights fremhever refill som en ressurs som blokkerer rendering.

Og det mest lumske: visuelt fungerer nettstedet. Du får bare en «gul» hastighetsscore og forstår ikke umiddelbart hvor du skal grave. Nettleserkonsollen er stille, ingen feil, bare tall i rapporten.

Video: hva annet du kan gjøre med Contact Form 7-skript

Denne korte engelskspråklige videoen viser en alternativ tilnærming, betinget lasting av CF7-skript og -stiler. Teknikkene fra videoen kombineres perfekt med vår fiks (vi dekker det nedenfor).

Steg-for-steg-fiks: deaktiver refill i controller.php

Steg 1. Finn filen

Sti til filen inne i utvidelsesmappen:

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

To måter å komme dit på. Via hostingspanelet: filbehandler i cPanel (File Manager) eller tilsvarende, utvid mappetreet langs stien over. Via FTP: koble til med en klient som FileZilla og naviger til nettstedskatalogen.

Steg 2. Finn WP_CACHE-blokken

Åpne controller.php i et hvilket som helst tekstredigeringsprogram. Finn tre linjer:

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

Mekanikken er enkel: hvis WP_CACHE er definert og aktiv, setter utvidelsen flagget cached = 1. Dette flagget utløser en kaskade av refill-forespørsler. Ifølge Contact Form 7-kildekoden, i versjon 6.1.6 (mai 2026) er blokken på samme sted og har ikke endret seg, gjennom hele 6.x-grenens historie har den ikke blitt rørt en eneste gang.

Steg 3. Kommenter ut eller slett

Det er tryggere å kommentere. Sett // i begynnelsen av hver linje:

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

Hvorfor kommentere i stedet for å slette: ved neste utvidelsesoppdatering vil controller.php bli overskrevet, og redigeringen vil gå tapt. Du vil kjenne igjen den utkommenterte blokken umiddelbart: åpnet filen, så //, husket. Sletting fungerer like godt, men om en måned eller to er det lett å glemme nøyaktig hva du kuttet. Lagre filen.

Steg 4. Tøm hurtigbuffer og kontroller på nytt

Etter redigeringen, sørg for å tømme hurtigbuffer på alle nivåer:

• Utvidelsesbuffer: WP Rocket → Dashboard → Clear Cache; W3 Total Cache → Performance → Purge All Caches; LiteSpeed Cache → LiteSpeed Cache → Purge All; FlyingPress → FlyingPress → Clear Cache.
• Tjenerbuffer: hvis hosten kjører Varnish, Nginx FastCGI eller LiteSpeed LSCache på tjenernivå, finnes det en tømmeknapp i hostingpanelet.
• CDN: Cloudflare eller QUIC.cloud → Purge Everything.

Kjør nå en gjentatt test i PageSpeed Insights eller GTmetrix. Åpne i inkognitomodus, nettleserbuffer kan vise den gamle versjonen av rapporten.

Feilen med /wp-json/contact-form-7/v1/contact-forms/<id>/refill bør forsvinne fra seksjonen «Eliminate render-blocking resources» eller «Reduce unused JavaScript». Fortsatt der? Sjekk controller.php (redigeringen kan ha feilet ved lagring) og objektbuffer (Redis/Object Cache beholder noen ganger den gamle filversjonen i minnet).

Hva du trenger å vite etter fiksen

Redigeringen er ikke permanent. Hver Contact Form 7-oppdatering overskriver controller.php, og de tre linjene kommer tilbake. Etter en oppdatering, åpne filen, forsikre deg om at blokken er aktiv igjen, og kommenter den ut på nytt. Ett minutts arbeid, men lett å glemme, ha en sjekkliste.

CAPTCHA kan slutte å fungere. Refill ble opprinnelig designet for CAPTCHA på bufrede sider. Hvis du bruker Contact Form 7s innebygde CAPTCHA (ikke Google reCAPTCHA), vil verifiseringskoden slutte å oppdateres etter at refill er deaktivert, og skjemaet vil ikke sendes inn. To løsninger: bytt til Google reCAPTCHA v3, det fungerer gjennom et separat API og er ikke avhengig av refill; eller ikke kommenter ut controller.php, men sett opp betinget lasting av CF7-ressurser gjennom filtre (mer om dette nedenfor). Testet etter redigeringen, sender skjemaet normalt? Flott, glem det.

Alternativ tilnærming, filtrene wpcf7_load_js og wpcf7_load_css. De deaktiverer ikke refill, men forhindrer Contact Form 7 fra å laste skript og stiler på sider uten skjema. Legg til i temaets functions.php:

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

Og på siden med skjemaet, inne i wp_head-hooken, returner flaggene til true. Dette fjerner unødvendige ressurser fra alle steder unntatt sider med skjemaer. Kombiner med deaktivering av refill gjennom controller.php for å oppnå maksimal ytelse.

⁉️🤔 Ofte stilte spørsmål

Er det obligatorisk å redigere controller.php hvis jeg ikke bruker CAPTCHA?

Ja, obligatorisk. Refill-forespørsler til /wp-json/contact-form-7/v1/contact-forms/<id>/refill sendes ved hver AJAX-syklus uavhengig av CAPTCHA-innstillinger. Visuelt legger du ikke merke til dem, men GTmetrix og Query Monitor registrerer unødvendige REST API-kall. Etter å ha kommentert ut de tre linjene, slutter endepunktet å svare, og hastigheten øker.

Hvorfor ikke bare deaktivere WP_CACHE i wp-config.php?

Konstanten WP_CACHE er et signal for hele WordPress-økosystemet om at sider kan hurtigbufres. WP Rocket, W3 Total Cache, FlyingPress og andre utvidelser er avhengige av den. Ved å fjerne WP_CACHE vil du ødelegge caching fullstendig, hastighetsfallet vil være langt mer merkbart enn én refill-forespørsel. Den riktige måten: behold caching, men kutt ut bivirkningen i CF7.

Vil fiksen fungere på multisite?

Den vil fungere, men wp-content/plugins/contact-form-7/includes/controller.php er delt på tvers av hele nettverket. Redigeringen vil påvirke alle undersider samtidig. Før du gjør endringer, sjekk om andre sider i nettverket har skjemaer med Contact Form 7s innebygde CAPTCHA. Hvis ja, test innsending på hver enkelt etter redigeringen, eller vurder et filterunntak i stedet for en global redigering.

Kan man automatisere gjeninnføring av redigeringen etter en utvidelsesoppdatering?

Contact Form 7-dokumentasjonen har ikke et ferdig filter for å erstatte akkurat disse tre linjene. I praksis er en sjekkliste «etter CF7-oppdatering → sjekk controller.php» mer pålitelig enn noe tilpasset mu-plugin. Filen endres sjelden, gjennom hele 6.x-grenen har ikke WP_CACHE-blokken blitt redigert en eneste gang.

Skjemaet sluttet å sende inn etter redigeringen, hva gjør jeg?

Sjekk først CAPTCHA-typen: Contact Form 7 → Integration. Utvidelsens innebygde CAPTCHA (ikke reCAPTCHA) er avhengig av refill for å endre verifiseringskoden. Bytt til Google reCAPTCHA v3, det fungerer gjennom sitt eget API og er ikke knyttet til refill. Andre alternativ: tilbakestill controller.php-redigeringen, la refill være aktivert og sett opp betinget lasting av CF7-ressurser kun på sider med skjemaer gjennom wpcf7_load_js og wpcf7_load_css.

Contact Form 7 og caching: hva du bør gjøre i 2026

Å redigere controller.php er mikrokirurgi som fjerner utvidelsens eneste smale flaskehals. Ett minutt av tiden din, ingen ekstra utvidelser, fungerer på WordPress fra 6.0 til 7.0 og alle gjeldende Contact Form 7-bygg.

Ønsker du å presse ut maksimum? Kombiner: deaktiver refill gjennom controller.php og sett opp betinget ressurslasting gjennom wpcf7_load_js- og wpcf7_load_css-filtrene. Det første fjerner refill-forespørsler, det andre forhindrer at skjemaskripter henger på sider uten skjemaer. Sammen tar de Contact Form 7 ut av PageSpeed Insights-rapporter som en kilde til problemer, fullstendig.

🔗 Contact Form 7 på WordPress.org