Hur CF7 saktar ner din sajt och varför du kan fixa det på 5 minuter

Contact Form 7 är installerat på över 5 miljoner WordPress-sajter. Pluginet är pålitligt, flexibelt och gratis, och kontaktformulär byggda med det fungerar på praktiskt taget varje sajt. Men denna bekvämlighet har en baksida: som standard laddar CF7 sin CSS och JavaScript på varenda sida på din sajt, även när det inte finns något formulär i närheten.

För startsidan, bloggen, landningssidor och dussintals andra sidor är detta dödvikt: extra anrop, ökad DOM Content Loaded, uppblåst sidstorlek. I siffror handlar det om ungefär 10-30 KB komprimerad trafik och 1-2 blockerande anrop helt i onödan. PageSpeed Insights förlåter inte sådant.

Detta kan fixas på tre sätt, från en enkel tvåraders defer till noggrann villkorlig inläsning "enligt regelboken" från pluginutvecklaren. Vi går igenom varje, med kod och utan utfyllnad.

💡 Snabb översikt:

• Inaktivera global CF7-inläsning via konstanterna WPCF7_LOAD_JS och WPCF7_LOAD_CSS i wp-config.php, den renaste officiella metoden.
• Återaktivera skript och stilmallar, men bara på sidor med ett formulär, via wpcf7_enqueue_scripts() i sidmallen.
• För anpassade byggen, paketet lazy-cf7-assets, som automatiskt hittar formuläret på sidan och laddar JS dynamiskt.

Metod 1: defer-ladda CF7-skriptet via functions.php

Det snabbaste och enklaste alternativet är att lägga till attributet defer på Contact Form 7-skriptet. Det säger till webbläsaren: "ladda filen i bakgrunden, men kör den när DOM:en är klar". Formuläret fortsätter att fungera, men skriptet blockerar inte längre sidrenderingen.

Lägg till denna kod i functions.php i ditt aktiva tema (eller via tillägget Code Snippets, säkrare vid uppdateringar):

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
}

Funktionen kontrollerar URL:en för varje inläst skript via hooken clean_url. Om adressen innehåller contact-form-7 och filändelsen .js, lägger den till defer='defer'. Alla andra skript lämnas orörda.

Plus: en lösning på 10 rader som inte kräver redigering av mallar eller plugininställningar. Passar för teman där det inte finns någon separat kontakt sidmall.

Minus: skriptet laddas fortfarande på varje sida, du tar bara bort det renderingsblockerande beteendet. Trafik och serveranrop minskas inte. Denna metod påverkar inte pluginets CSS alls, stilmallen laddas som vanligt.

Metod 2: officiell metod, villkorlig inläsning via konstanter

Detta tillvägagångssätt beskrivs i Contact Form 7-dokumentationen av pluginutvecklaren själv, Takayuki Miyoshi. Idén har två steg: inaktivera först CF7-skript och stilmallar globalt, och aktivera dem sedan igen, men bara på sidor där formuläret faktiskt används.

Steg 1: inaktivera inläsning på alla sidor

Lägg till två konstanter i wp-config.php:

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

Alternativt, via ditt temas functions.php:

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

Efter detta kommer CF7 inte att ladda en enda rad av sin kod på någon sida på din webbplats, inklusive de där ett formulär finns. Utan skript förlorar formuläret AJAX-inskick och validering, så steg 2 behövs.

Steg 2: återställ skript på sidor med ett formulär

Låt oss säga att din kontaktsida använder mallen page-contact.php i din temamapp. Lägg till detta i den mallen innan du anropar 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
}

Funktionerna wpcf7_enqueue_scripts() och wpcf7_enqueue_styles() laddar manuellt in CF7-skript och stilar enbart på denna mall. Alla andra sidor på din webbplats förblir rena.

Plus: metoden är "från tillverkaren", garanterat att den inte går sönder vid plugin-uppdateringar. Fungerar med CF7 version 5.x och 6.x, aktuell version 6.1.6 i juni 2026 (versionslista). Noll onödig inläsning på sidor utan formulär.

Minus: kräver redigering av temamallar. Om du har flera sidor med formulär måste du komma ihåg att lägga till anropen i varje mall. Om formuläret infogas via en shortcode i innehållet (snarare än i en mall) fungerar metoden inte utan ytterligare villkor.

Metod 3: paketet lazy-cf7-assets för JavaScript-bundles

Om du bygger ditt frontend med en bundler (Webpack, Vite, esbuild) och använder ett modernt tema med en anpassad JavaScript-bundle finns det ett npm-paket som heter lazy-cf7-assets. Det löser samma problem, men på klientsidan: det skannar DOM:en, hittar CF7-formuläret och laddar först därefter dynamiskt in plugin-skripten.

Installation:

1
npm install lazy-cf7-assets

Innan du använder det måste du inaktivera automatisk JS-inläsning från pluginet (som i metod 2, via wpcf7_load_js):

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

Sedan i din JS-bundle:

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

Om skript laddas i <head> snarare än i slutet av <body>, ange en absolut sökväg till laddnings-GIF-bilden så att formuläret inte "flimrar" i ett tomt tillstånd:

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

Plus: noll ingrepp på PHP-sidan, inget behov av att redigera mallar för varje sida med ett formulär. Paketet upptäcker automatiskt om en CF7-shortcode finns på sidan och laddar skript endast då. Passar för webbplatser där formuläret matas ut via shortcode i innehåll (snarare än hårdkodat i en mall).

Minus: fungerar bara med JavaScript (pluginets CSS måste fortfarande inaktiveras separat). Kräver en bundler i projektet. Paketet är minimalt (1 stjärna på GitHub), underhålls av en enskild utvecklare, för produktion bör du forka det och kontrollera CF7-uppdateringar för kompatibilitet.

Vad ska man välja: jämförelse av tre tillvägagångssätt

Om ditt formulär finns på en enda sida i en separat mall, använd metod 2 (officiella metoden). Om webbplatsen använder en modern bundler och du kan ha flera formulär på olika ställen, metod 3 (lazy-cf7-assets). Om du behöver en lösning "på direkten" utan att redigera mallar, metod 1 (defer), men kom ihåg begränsningarna.

En viktig brasklapp: efter någon av dessa ändringar, se till att verifiera att formuläret skickas, validering fungerar, reCAPTCHA inte är trasig och stilar inte har förskjutits. Öppna sidan med formuläret i inkognitoläge, fyll i och skicka ett testmeddelande före och efter.

⁉️🤔 Vanliga frågor

Varför laddar CF7 skript på alla sidor överhuvudtaget?

Pluginet vet inte i WordPress laddningsfas om en specifik sida innehåller en formulärshortcode. WordPress sätter ihop sidan senare, när skriptkön redan har byggts upp. Utvecklaren Takayuki Miyoshi förklarar detta i den officiella dokumentationen: det är tekniskt omöjligt att upptäcka närvaron av en shortcode före wp_head-hooken. Därför valdes en konservativ approach, att alltid ladda. Detta är ett medvetet arkitektoniskt beslut, inte en bugg: pluginet offrar prestanda för garanterad funktionalitet. Bördan av optimering läggs över på webbplatsutvecklaren.

Kommer formuläret att sluta fungera efter att global laddning inaktiverats?

Nej, om du noggrant återaktiverar skripten på de sidor som behövs. Formuläret förlorar AJAX-inskick och validering på klientsidan endast på sidor där skript inte är inkluderade. Det är därför steg 2 (återställa skript) är obligatoriskt, stanna inte vid bara WPCF7_LOAD_JS = false. Kontrollera anropsordningen: wpcf7_enqueue_scripts() ska komma före wp_head(), inte efter. Och se till att reCAPTCHA inte krockar med defer-laddning.

Fungerar konstantmetoden med CF7 6.x?

Ja, konstanterna WPCF7_LOAD_JS och WPCF7_LOAD_CSS stöds fullt ut i den aktuella versionen 6.1.6 (se officiell versionslogg). Genom hela pluginet historia, från version 3.9 till nuvarande 6.x, har dessa konstanter aldrig deklarerats som föråldrade. Detta är den mest stabila och dokumenterade metoden för att hantera laddning.

Vad gör jag om jag har flera formulär på olika ställen?

Om formulär är utspridda över olika sidor via shortcodes i innehåll (snarare än i mallar), är den officiella metoden med mallar opraktisk. Använd antingen lazy-cf7-assets (metod 3), eller pluginet Conditionally Load CF7: det lägger till en inställning i adminpanelen för vilka sidor/inläggstyper som ska ladda skript, och fungerar utan kodredigering.

Tre rader kod mot dussintals förfrågningar

Problemet med att "CF7 laddar skript överallt" har funnits exakt lika länge som pluginet självt, och under 10+ år har utvecklaren inte ändrat standardbeteendet, eftersom det är en kompromiss mellan enkelhet och prestanda. Men en kompromiss, inte en dom.

Den säkraste vägen är den officiella metoden med konstanter och mallar. Den tar bort pluginets skript och stilmallar från alla sidor utom de där de behövs, och går inte sönder vid uppdateringar. Om din webbplats använder en modern stack med en bundler, ta en titt på lazy-cf7-assets. Om du behöver något snabbt och utan att redigera mallar, kommer defer via clean_url-hooken att ge dig mätbara förbättringar redan idag.

Kontrollera din webbplats via PageSpeed Insights före och efter, att minska antalet blockerande förfrågningar med 1-2 enheter och spara 10-30 KB per sida kan höja prestandapoängen med 2-5 poäng, särskilt på mobila enheter.