Hvordan CF7 gjør nettstedet ditt tregere og hvorfor du kan fikse det på 5 minutter

Contact Form 7 er installert på over 5 millioner WordPress-nettsteder. Utvidelsen er pålitelig, fleksibel og gratis, og kontaktskjemaer bygget med den fungerer på praktisk talt alle nettsteder. Men denne bekvemmeligheten har en bakside: som standard laster CF7 inn sin CSS og JavaScript på hver side på nettstedet ditt, selv når det ikke finnes noe skjema i nærheten.

For hjemmesiden, bloggen, landingssider og dusinvis av andre sider er dette dødvekt: ekstra forespørsler, økt DOM Content Loaded, oppblåst sidestørrelse. I tall betyr det omtrent 10-30 KB komprimert trafikk og 1-2 blokkerende forespørsler uten grunn. PageSpeed Insights tilgir ikke slikt.

Dette kan fikses på tre måter, fra en primitiv to-linjers utsettelse til nøye betinget innlasting «etter boka» fra utvidelsesutvikleren. Vi går gjennom hver enkelt, med kode og uten fyll.

💡 Rask oversikt:

• Deaktiver global CF7-innlasting via konstantene WPCF7_LOAD_JS og WPCF7_LOAD_CSS i wp-config.php, den ryddigste offisielle metoden.
• Aktiver skript og stiler på nytt, men bare på sider med et skjema, via wpcf7_enqueue_scripts() i sidemalen.
• For egendefinerte bunter, pakken lazy-cf7-assets, som automatisk finner skjemaet på siden og laster JS dynamisk.

Metode 1: utsett lasting av CF7-skriptet via functions.php

Det raskeste og enkleste alternativet er å legge til attributtet defer på Contact Form 7-skriptet. Det forteller nettleseren: «last filen i bakgrunnen, men kjør den når DOM-en er klar». Skjemaet fortsetter å fungere, men skriptet blokkerer ikke lenger sidegjengivelsen.

Legg til denne koden i functions.php i ditt aktive tema (eller via utvidelsen Code Snippets, tryggere ved oppdateringer):

1
if ( ! function_exists( 'add_defer_to_cf7' ) ) {
2
    function add_defer_to_cf7( $url ) {
3
        if (
4
            false === strpos( $url, 'contact-form-7' ) ||
5
            false === strpos( $url, '.js' )
6
        ) {
7
            return $url;
8
        }
9
        return "$url' defer='defer";
10
    }
11
    add_filter( 'clean_url', 'add_defer_to_cf7', 11, 1 );
12
}

Funksjonen sjekker URL-en til hvert skript som er satt i kø via kroken clean_url. Hvis adressen inneholder contact-form-7 og filendelsen .js, legger den til defer='defer'. Alle andre skript forblir urørte.

Pluss: en løsning på 10 linjer som ikke krever redigering av maler eller utvidelseskonfigurasjon. Passer for temaer der det ikke finnes en egen kontaktsidemal.

Minus: skriptet lastes fortsatt på hver side, du fjerner bare den gjengivelsesblokkerende oppførselen. Trafikk og serverforespørsler reduseres ikke. Denne metoden påvirker ikke utvidelsens CSS i det hele tatt, stilarket lastes som vanlig.

Metode 2: offisiell metode, betinget innlasting via konstanter

Denne tilnærmingen er beskrevet i Contact Form 7-dokumentasjonen av utvidelsesutvikleren selv, Takayuki Miyoshi. Ideen har to trinn: først deaktiver CF7-skript og -stiler globalt, og aktiver dem deretter igjen, men bare på sider der skjemaet faktisk brukes.

Trinn 1: deaktiver innlasting på alle sider

Legg til to konstanter i wp-config.php:

1
define( 'WPCF7_LOAD_JS', false );
2
define( 'WPCF7_LOAD_CSS', false );

Alternativt, via temaets functions.php:

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

Etter dette vil ikke CF7 laste en eneste linje av koden sin på noen side av nettstedet ditt, inkludert de sidene der et skjema finnes. Uten skript mister skjemaet AJAX-innsending og validering, så steg 2 er nødvendig.

Steg 2: gjenopprett skript på sider med et skjema

La oss si at kontaktsiden din bruker malen page-contact.php i temamappen din. Legg til dette i den malen før du kaller wp_head():

1
if ( function_exists( 'wpcf7_enqueue_scripts' ) ) {
2
    wpcf7_enqueue_scripts();
3
}
4
 
5
if ( function_exists( 'wpcf7_enqueue_styles' ) ) {
6
    wpcf7_enqueue_styles();
7
}

Funksjonene wpcf7_enqueue_scripts() og wpcf7_enqueue_styles() legger manuelt til CF7-skript og -stiler kun på denne malen. Alle andre sider på nettstedet ditt forblir rene.

Pluss: metoden er «fra produsenten», garantert å ikke bli ødelagt ved plugin-oppdateringer. Fungerer med CF7 versjon 5.x og 6.x, gjeldende versjon 6.1.6 per juni 2026 (utgivelsesliste). Null unødvendig lasting på sider uten skjema.

Minus: krever redigering av temamaler. Hvis du har flere sider med skjemaer, må du huske å legge til kallene i hver mal. Hvis skjemaet settes inn via kortkode i innholdet (i stedet for i en mal), vil metoden ikke fungere uten ytterligere betingelser.

Metode 3: lazy-cf7-assets-pakken for JavaScript-bunter

Hvis du bygger frontenden din med en bundler (Webpack, Vite, esbuild) og bruker et moderne tema med en tilpasset JavaScript-bunt, finnes det en npm-pakke kalt lazy-cf7-assets. Den løser det samme problemet, men på klientsiden: den skanner DOM-en, finner CF7-skjemaet og laster først da inn plugin-skriptene dynamisk.

Installasjon:

1
npm install lazy-cf7-assets

Før du bruker den, må du deaktivere automatisk JS-lasting fra plugin-en (som i metode 2, via wpcf7_load_js):

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

Deretter i JS-bunten din:

1
import lazyform from 'lazy-cf7-assets';
2
 
3
// Initialize after DOM ready
4
lazyform.init();

Hvis skript lastes i <head> i stedet for på slutten av <body>, spesifiser en absolutt bane til laste-GIF-bildet slik at skjemaet ikke «flimrer» i en tom tilstand:

1
lazyform.init({
2
    gifPath: '/wp-content/themes/my-theme/images/ajax-loader.gif'
3
});

Pluss: null berøring på PHP-siden, ikke nødvendig å redigere maler for hver side med et skjema. Pakken oppdager automatisk om en CF7-kortkode finnes på siden og laster kun skript da. Egnet for nettsteder der skjemaet vises via kortkode i innhold (i stedet for hardkodet i en mal).

Minus: fungerer kun med JavaScript (plugin-ens CSS må fortsatt deaktiveres separat). Krever en bundler i prosjektet. Pakken er minimal (1 stjerne på GitHub), vedlikeholdes av en enkelt utvikler, for produksjon bør du forke den og sjekke CF7-oppdateringer for kompatibilitet.

Hva du bør velge: sammenligning av tre tilnærminger

Hvis skjemaet ditt ligger på en enkelt side i en separat mal, bruk metode 2 (offisiell metode). Hvis nettstedet bruker en moderne bundler og du kan ha flere skjemaer på forskjellige steder, bruk metode 3 (lazy-cf7-assets). Hvis du trenger en løsning «akkurat nå» uten å redigere maler, bruk metode 1 (utsett), men husk begrensningene.

Et viktig forbehold: etter noen av disse endringene, sørg for å verifisere at skjemaet sender inn, validering fungerer, reCAPTCHA ikke er ødelagt, og at stiler ikke har forskjøvet seg. Åpne siden med skjemaet i inkognitomodus, fyll ut og send en testmelding før og etter.

⁉️🤔 Ofte stilte spørsmål

Hvorfor laster CF7 skript på alle sider uansett?

Utvidelsen vet ikke på WordPress' oppstartstidspunkt om en bestemt side inneholder en skjemashortcode. WordPress setter sammen siden senere, når skriptkøen allerede er dannet. Utvikler Takayuki Miyoshi forklarer dette i den offisielle dokumentasjonen: det er teknisk umulig å oppdage tilstedeværelsen av en shortcode før wp_head-kroken. Derfor ble en konservativ tilnærming valgt, å alltid laste inn. Dette er et bevisst arkitektonisk valg, ikke en feil: utvidelsen ofrer ytelse for garantert funksjonalitet. Byrden med optimalisering overføres til nettstedsutvikleren.

Vil skjemaet slutte å fungere etter at global lasting er deaktivert?

Nei, hvis du nøye aktiverer skriptene på nytt på de nødvendige sidene. Skjemaet vil miste AJAX-innsending og validering på klientsiden kun på sider der skript ikke er inkludert. Derfor er steg 2 (gjenoppretting av skript) obligatorisk, ikke stopp ved bare WPCF7_LOAD_JS = false. Sjekk rekkefølgen på kall: wpcf7_enqueue_scripts() bør komme før wp_head(), ikke etter. Og sørg for at reCAPTCHA ikke kommer i konflikt med utsatt lasting.

Fungerer konstantmetoden med CF7 6.x?

Ja, konstantene WPCF7_LOAD_JS og WPCF7_LOAD_CSS er fullt støttet i gjeldende versjon 6.1.6 (se offisiell versjonslogg). Gjennom hele utvidelsens historie, fra versjon 3.9 til dagens 6.x, har disse konstantene aldri blitt erklært som utdaterte. Dette er den mest stabile og dokumenterte metoden for å administrere lasting.

Hva om jeg har flere skjemaer på forskjellige steder?

Hvis skjemaer er spredt over forskjellige sider via shortcoder i innhold (i stedet for i maler), er den offisielle metoden med maler upraktisk. Bruk enten lazy-cf7-assets (metode 3), eller utvidelsen Conditionally Load CF7: den legger til en innstilling i administrasjonspanelet for hvilke sider/innholdstyper som skal laste skript, og fungerer uten koderedigering.

Tre linjer kode mot dusinvis av forespørsler

Problemet med at «CF7 laster skript overalt» har eksistert nøyaktig like lenge som selve utvidelsen, og over 10+ år har utvikleren ikke endret standardoppførselen, fordi det er et kompromiss mellom enkelhet og ytelse. Men et kompromiss, ikke en dom.

Den tryggeste veien er den offisielle metoden med konstanter og maler. Den fjerner utvidelsens skript og stilsett fra alle sider unntatt de der de trengs, og ødelegges ikke under oppdateringer. Hvis nettstedet ditt bruker en moderne stack med en bundler, ta en titt på lazy-cf7-assets. Hvis du trenger noe raskt og uten å redigere maler, vil utsettelse via clean_url-kroken gi deg metriske forbedringer i dag.

Sjekk nettstedet ditt via PageSpeed Insights før og etter, å redusere antall blokkerende forespørsler med 1-2 enheter og spare 10-30 KB per side kan øke ytelsesscoren med 2-5 poeng, spesielt på mobile enheter.