Miten CF7 hidastaa sivustoasi ja miksi voit korjata sen 5 minuutissa

Contact Form 7 on asennettu yli 5 miljoonalle WordPress-sivustolle. Lisäosa on luotettava, joustava ja ilmainen, ja sillä rakennetut yhteydenottolomakkeet toimivat käytännössä jokaisella sivustolla. Mutta tällä mukavuudella on kääntöpuolensa: oletuksena CF7 lataa CSS- ja JavaScript-tiedostonsa jokaisella sivustosi sivulla, vaikka lomaketta ei olisi mailla halmeilla.

Etusivulle, blogille, laskeutumissivuille ja kymmenille muille sivuille tämä on turhaa painolastia: ylimääräisiä pyyntöjä, kasvanut DOM Content Loaded -aika, paisunut sivukoko. Numeroina noin 10-30 kt pakattua liikennettä ja 1-2 blokkaavaa pyyntöä ilman mitään syytä. PageSpeed Insights ei anna tällaisia asioita anteeksi.

Tämän voi korjata kolmella tavalla, aina alkeellisesta kaksirivisestä defer-viivästyksestä huolelliseen ehdolliseen lataukseen "oppikirjan mukaan" lisäosan kehittäjältä. Käymme läpi jokaisen, koodin kera ja ilman höttöä.

💡 Pika yhteenveto:

• Poista CF7:n yleinen lataus käytöstä WPCF7_LOAD_JS- ja WPCF7_LOAD_CSS-vakioilla wp-config.php-tiedostossa, siistein virallinen tapa.
• Ota skriptit ja tyylit uudelleen käyttöön, mutta vain sivuilla, joilla on lomake, wpcf7_enqueue_scripts()-funktiolla sivupohjassa.
• Mukautetuille nipuille lazy-cf7-assets-paketti, joka etsii lomakkeen sivulta automaattisesti ja lataa JavaScriptin dynaamisesti.

Tapa 1: CF7-skriptin defer-lataus functions.php:n kautta

Nopein ja yksinkertaisin vaihtoehto on lisätä defer-attribuutti Contact Form 7-skriptiin. Se kertoo selaimelle: "lataa tiedosto taustalla, mutta suorita se, kun DOM on valmis". Lomake toimii edelleen, mutta skripti ei enää blokkaa sivun renderöintiä.

Lisää tämä koodi aktiivisen teemasi functions.php-tiedostoon (tai Code Snippets -lisäosan kautta, turvallisempaa päivitysten yhteydessä):

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
}

Funktio tarkistaa jokaisen jonoon asetetun skriptin URL-osoitteen clean_url-koukun kautta. Jos osoite sisältää contact-form-7 ja .js-päätteen, se lisää defer='defer'. Kaikki muut skriptit jätetään koskematta.

Plussaa: ratkaisu 10 rivillä, joka ei vaadi pohjien tai lisäosan asetusten muokkaamista. Sopii teemoille, joissa ei ole erillistä yhteydenottosivupohjaa.

Miinusta: skripti latautuu edelleen jokaisella sivulla, poistat vain renderöinnin blokkauksen. Liikenne ja palvelinpyynnöt eivät vähene. Tämä tapa ei vaikuta lisäosan CSS:ään lainkaan, tyylitiedosto latautuu normaalisti.

Tapa 2: virallinen tapa, ehdollinen lataus vakioiden avulla

Tämä lähestymistapa on kuvattu Contact Form 7:n dokumentaatiossa lisäosan kehittäjän, Takayuki Miyoshin, itsensä toimesta. Ideassa on kaksi vaihetta: ensin poistetaan CF7-skriptit ja -tyylit yleisesti käytöstä, sitten otetaan ne uudelleen käyttöön, mutta vain sivuilla, joilla lomaketta oikeasti käytetään.

Vaihe 1: poista lataus käytöstä kaikilla sivuilla

Lisää kaksi vakiota wp-config.php-tiedostoon:

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

Vaihtoehtoisesti teemasi functions.php-tiedoston kautta:

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

Tämän jälkeen CF7 ei lataa riviäkään koodiaan yhdelläkään sivustosi sivulla, ei edes niillä, joilla lomake on. Ilman skriptejä lomake menettää AJAX-lähetyksen ja validoinnin, joten vaihe 2 on tarpeen.

Vaihe 2: palauta skriptit sivuille, joilla on lomake

Oletetaan, että yhteydenottosivusi käyttää teemakansiossasi olevaa page-contact.php-pohjaa. Lisää tämä kyseiseen pohjaan ennen wp_head()-kutsua:

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
}

Funktiot wpcf7_enqueue_scripts() ja wpcf7_enqueue_styles() lataavat CF7:n skriptit ja tyylit käsin vain tällä pohjalla. Kaikki muut sivustosi sivut pysyvät puhtaina.

Plussaa: menetelmä on "valmistajan oma", eikä se taatusti hajoa liitännäispäivitysten yhteydessä. Toimii CF7:n versioilla 5.x ja 6.x, nykyinen versio 6.1.6 kesäkuussa 2026 (julkaisulista). Ei lainkaan turhaa latausta sivuilla, joilla ei ole lomaketta.

Miinusta: vaatii teemapohjien muokkaamista. Jos sinulla on useita sivuja, joilla on lomakkeita, sinun täytyy muistaa lisätä kutsut jokaiseen pohjaan. Jos lomake on lisätty shortcodella sisältöön (eikä pohjaan), menetelmä ei toimi ilman lisäehtoja.

Menetelmä 3: lazy-cf7-assets-paketti JavaScript-bundleille

Jos rakennat frontendisi bundlerilla (Webpack, Vite, esbuild) ja käytät modernia teemaa, jossa on oma JavaScript-bundle, on olemassa npm-paketti nimeltä lazy-cf7-assets. Se ratkaisee saman ongelman, mutta asiakaspuolella: se skannaa DOM:n, löytää CF7-lomakkeen ja vasta sitten lataa liitännäisen skriptit dynaamisesti.

Asennus:

1
npm install lazy-cf7-assets

Ennen sen käyttöä sinun täytyy poistaa käytöstä liitännäisen automaattinen JS-lataus (kuten menetelmässä 2, wpcf7_load_js-asetuksella):

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

Sitten JS-bundlessasi:

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

Jos skriptit latautuvat <head>-osiossa eikä <body>-osion lopussa, määritä absoluuttinen polku lataus-GIF-kuvaan, jotta lomake ei "välky" tyhjässä tilassa:

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

Plussaa: PHP-puolella ei tarvitse koskea mihinkään, ei tarvetta muokata pohjia jokaiselle lomakkeelliselle sivulle. Paketti tunnistaa automaattisesti, onko sivulla CF7-shortcodea, ja lataa skriptit vain silloin. Sopii sivustoille, joilla lomake tulostetaan shortcodella sisällössä (eikä kovakoodattuna pohjaan).

Miinusta: toimii vain JavaScriptillä (liitännäisen CSS täytyy edelleen poistaa erikseen). Vaatii bundlerin projektissa. Paketti on minimaalinen (1 tähti GitHubissa), yhden kehittäjän ylläpitämä, tuotantokäyttöä varten se kannattaa forkata ja tarkistaa CF7-päivitysten yhteensopivuus.

Mitä valita: kolmen lähestymistavan vertailu

Jos lomakkeesi sijaitsee yhdellä sivulla erillisessä pohjassa, käytä menetelmää 2 (virallinen menetelmä). Jos sivusto käyttää modernia bundleria ja sinulla saattaa olla useita lomakkeita eri paikoissa, menetelmää 3 (lazy-cf7-assets). Jos tarvitset ratkaisun "heti" ilman pohjien muokkausta, menetelmää 1 (defer), mutta muista rajoitukset.

Yksi tärkeä huomio: minkä tahansa näistä muutoksista jälkeen varmista ehdottomasti, että lomake lähettää, validointi toimii, reCAPTCHA ei ole rikki ja tyylit eivät ole siirtyneet. Avaa lomakkeen sisältävä sivu incognito-tilassa, täytä ja lähetä testiviesti ennen ja jälkeen.

⁉️🤔 Usein kysytyt kysymykset

Miksi CF7 lataa skriptejä kaikilla sivuilla joka tapauksessa?

Lisäosa ei tiedä WordPressin latausvaiheessa, sisältääkö tietty sivu lomakkeen shortcodea. WordPress kokoaa sivun myöhemmin, kun skriptijono on jo muodostettu. Kehittäjä Takayuki Miyoshi selittää tämän virallisessa dokumentaatiossa: shortcoden olemassaoloa on teknisesti mahdotonta havaita ennen wp_head-koukkua. Siksi valittiin konservatiivinen lähestymistapa, eli ladataan aina. Tämä on tietoinen arkkitehtuurinen päätös, ei bugi: lisäosa uhraa suorituskykyä taatakseen toimintavarmuuden. Optimointivastuu siirretään sivuston kehittäjälle.

Hajoavatko lomakkeet, kun globaali lataus poistetaan käytöstä?

Eivät, jos otat skriptit huolellisesti uudelleen käyttöön tarvittavilla sivuilla. Lomake menettää AJAX-lähetyksen ja selainpuolen validoinnin vain sivuilla, joilla skriptejä ei ole mukana. Siksi vaihe 2 (skriptien palauttaminen) on pakollinen, älä jää pelkkään WPCF7_LOAD_JS = false -asetukseen. Tarkista kutsujärjestys: wpcf7_enqueue_scripts()-funktion tulee tulla ennen wp_head()-funktiota, ei sen jälkeen. Ja varmista, ettei reCAPTCHA ole ristiriidassa defer-latauksen kanssa.

Toimiiko vakioiden metodi CF7 6.x-version kanssa?

Kyllä, WPCF7_LOAD_JS- ja WPCF7_LOAD_CSS-vakiot ovat täysin tuettuja nykyisessä versiossa 6.1.6 (katso virallinen versioloki). Koko lisäosan historian ajan, versiosta 3.9 nykyiseen 6.x-versioon, näitä vakioita ei ole koskaan merkitty vanhentuneiksi. Tämä on vakain ja dokumentoiduin tapa hallita latausta.

Entä jos minulla on useita lomakkeita eri paikoissa?

Jos lomakkeet ovat hajallaan eri sivuilla shortcodeina sisällössä (eikä mallipohjissa), virallinen metodi mallipohjien kanssa on hankala. Käytä joko lazy-cf7-assets-ratkaisua (metodi 3) tai Conditionally Load CF7 -lisäosaa: se lisää hallintapaneeliin asetuksen, mille sivuille tai sisältötyypeille skriptit ladataan, ja toimii ilman koodin muokkaamista.

Kolme riviä koodia kymmeniä pyyntöjä vastaan

"CF7 lataa skriptejä kaikkialle" -ongelma on ollut olemassa täsmälleen yhtä kauan kuin itse lisäosa, eikä kehittäjä ole yli kymmeneen vuoteen muuttanut oletuskäyttäytymistä, koska kyse on kompromissista yksinkertaisuuden ja suorituskyvyn välillä. Mutta kyse on kompromissista, ei tuomiosta.

Turvallisin reitti on virallinen metodi, jossa käytetään vakioita ja mallipohjia. Se poistaa lisäosan skriptit ja tyylit kaikilta sivuilta paitsi niiltä, joilla niitä tarvitaan, eikä se hajoa päivitysten yhteydessä. Jos sivustosi käyttää modernia pinoa ja bundleria, tutustu lazy-cf7-assets-ratkaisuun. Jos tarvitset jotain nopeaa ja ilman mallipohjien muokkaamista, clean_url-koukun kautta tehtävä defer-lataus tuo mittariparannuksia jo tänään.

Tarkista sivustosi PageSpeed Insights -työkalulla ennen ja jälkeen muutosten: estävien pyyntöjen määrän vähentäminen yhdellä tai kahdella ja 10-30 kt:n säästö sivua kohden voivat nostaa Performance-pisteitä 2-5 pistettä, erityisesti mobiililaitteilla.