Kuidas CF7 teie saiti aeglustab ja miks saate selle 5 minutiga parandada

Contact Form 7 on paigaldatud enam kui 5 miljonile WordPressi saidile. Plugin on usaldusväärne, paindlik ja tasuta ning sellega ehitatud kontaktivormid töötavad praktiliselt igal saidil. Kuid sellel mugavusel on ka varjukülg: vaikimisi laadib CF7 oma CSS-i ja JavaScripti saidi igal lehel, isegi kui vormi pole seal läheduseski.

Kodulehe, blogi, sihtlehtede ja kümnete teiste lehtede jaoks on see surnud raskus: lisanõuded, suurenenud DOM Content Loaded, puhvitud lehe maht. Arvudes tähendab see umbes 10-30 KB tihendatud liiklust ja 1-2 blokeerivat päringut ilma igasuguse põhjuseta. PageSpeed Insights selliseid asju ei andesta.

Seda saab parandada kolmel viisil, alates primitiivsest kaherealisest edasilükkamisest kuni hoolika tingimusliku laadimiseni „nagu õpikus kirjas" plugina arendajalt. Käsitleme igaühte neist, koos koodiga ja ilma tühja jututa.

💡 Kiirülevaade:

• Keelake globaalne CF7 laadimine WPCF7_LOAD_JS ja WPCF7_LOAD_CSS konstantide kaudu failis wp-config.php, see on puhtaim ametlik meetod.
• Lubage skriptid ja stiilid uuesti, kuid ainult vormiga lehtedel, kasutades lehe mallis funktsiooni wpcf7_enqueue_scripts().
• Kohandatud komplektide jaoks pakett lazy-cf7-assets, mis tuvastab automaatselt lehel oleva vormi ja laadib JS-i dünaamiliselt.

1. Meetod: CF7 skripti edasilükatud laadimine faili functions.php kaudu

Kiireim ja lihtsaim variant on lisada atribuut defer Contact Form 7 skriptile. See ütleb brauserile: „laadi fail taustal, kuid käivita see siis, kui DOM on valmis". Vorm jätkab töötamist, kuid skript ei blokeeri enam lehe renderdamist.

Lisage see kood oma aktiivse teema faili functions.php (või Code Snippets plugina kaudu, mis on uuenduste ajal turvalisem):

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
}

Funktsioon kontrollib iga järjekorda pandud skripti URL-i clean_url konksu kaudu. Kui aadress sisaldab contact-form-7 ja .js laiendit, lisab see defer='defer'. Kõiki teisi skripte ei puudutata.

Pluss: lahendus 10 reaga, mis ei nõua mallide ega plugina konfiguratsiooni muutmist. Sobib teemadele, kus pole eraldi kontaktlehe malli.

Miinus: skript laaditakse endiselt igal lehel, eemaldate ainult renderdamist blokeeriva käitumise. Liiklus ja serveripäringud ei vähene. See meetod ei mõjuta üldse plugina CSS-i, stiilileht laaditakse nagu tavaliselt.

2. Meetod: ametlik meetod, tingimuslik laadimine konstantide kaudu

Seda lähenemist kirjeldab Contact Form 7 dokumentatsioonis plugina arendaja ise, Takayuki Miyoshi. Ideel on kaks sammu: esmalt keelake globaalselt CF7 skriptid ja stiilid, seejärel lubage need uuesti, kuid ainult lehtedel, kus vormi tegelikult kasutatakse.

1. Samm: keelake laadimine kõigil lehtedel

Lisage faili wp-config.php kaks konstanti:

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

Alternatiivselt oma teema functions.php kaudu:

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

Pärast seda ei laadi CF7 ühtegi koodirida ühelgi sinu saidi lehel, kaasa arvatud neil, kus vorm asub. Skriptideta kaotab vorm AJAX-i kaudu saatmise ja valideerimise, seega on vaja 2. sammu.

2. Samm: taasta skriptid lehtedel, kus vorm on

Oletame, et sinu kontaktleht kasutab sinu teema kaustas malli page-contact.php. Lisa see mallile enne wp_head() väljakutset:

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
}

Funktsioonid wpcf7_enqueue_scripts() ja wpcf7_enqueue_styles() laadivad CF7 skriptid ja stiilid käsitsi ainult sellel mallil. Kõik teised sinu saidi lehed jäävad puhtaks.

Pluss: meetod on „tootja poolt", garanteeritult ei purune pistikprogrammi uuenduste käigus. Töötab CF7 versioonidega 5.x ja 6.x, praegune versioon 6.1.6 juuni 2026 seisuga (väljalasete nimekiri). Null üleliigset laadimist lehtedel, kus vormi pole.

Miinus: nõuab teema mallide muutmist. Kui sul on mitu lehte vormidega, pead meeles pidama väljakutsete lisamist igale mallile. Kui vorm on lisatud lühikoodi kaudu sisusse (mitte malli), ei tööta meetod ilma lisatingimusteta.

3. Meetod: lazy-cf7-assets pakett JavaScripti komplektidele

Kui sa ehitad oma esikülge komplekteerijaga (Webpack, Vite, esbuild) ja kasutad kaasaegset teemat kohandatud JavaScripti komplektiga, on olemas npm pakett nimega lazy-cf7-assets. See lahendab sama probleemi, kuid kliendi poolel: see skannib DOM-i, leiab CF7 vormi ja alles seejärel laadib dünaamiliselt pistikprogrammi skriptid.

Paigaldamine:

1
npm install lazy-cf7-assets

Enne selle kasutamist pead keelama pistikprogrammi automaatse JS-i laadimise (nagu 2. meetodis, wpcf7_load_js kaudu):

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

Seejärel oma JS komplektis:

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

Kui skriptid laaditakse <head>-is, mitte <body> lõpus, määra absoluutne tee laadimise GIF-pildile, et vorm ei „vilkuma" hakkaks tühjas olekus:

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

Pluss: PHP poolel null puudutust, pole vaja malle muuta iga vormiga lehe jaoks. Pakett tuvastab automaatselt, kas lehel on CF7 lühikood, ja laadib skriptid ainult siis. Sobib saitidele, kus vorm väljastatakse lühikoodi kaudu sisus (mitte malli sisse kodeeritult).

Miinus: töötab ainult JavaScriptiga (pistikprogrammi CSS tuleb endiselt eraldi keelata). Nõuab projektis komplekteerijat. Pakett on minimaalne (1 tärn GitHubis), seda haldab üks arendaja, toodangu jaoks peaksid selle kahveldama ja kontrollima CF7 uuenduste ühilduvust.

Mida valida: kolme lähenemisviisi võrdlus

Kui sinu vorm asub ühel lehel eraldi mallis, kasuta 2. meetodit (ametlik meetod). Kui sait kasutab kaasaegset komplekteerijat ja sul võib olla mitu vormi erinevates kohtades, siis 3. meetodit (lazy-cf7-assets). Kui vajad lahendust „kohe praegu" ilma malle muutmata, siis 1. meetodit (edasilükkamine), kuid pea meeles piiranguid.

Üks oluline hoiatus: pärast ükskõik millist neist muudatustest kontrolli kindlasti, et vorm saadab, valideerimine töötab, reCAPTCHA pole katki ja stiilid pole nihkunud. Ava leht vormiga inkognito režiimis, täida ja saada testsõnum enne ja pärast.

⁉️🤔 Korduma kippuvad küsimused

Miks CF7 üldse kõigil lehtedel skripte laadib?

Plugin ei tea WordPressi laadimise etapis, kas konkreetne leht sisaldab vormi lühikoodi. WordPress koostab lehe hiljem, kui skriptijärjekord on juba moodustatud. Arendaja Takayuki Miyoshi selgitab seda ametlikus dokumentatsioonis: lühikoodi olemasolu tuvastamine enne wp_head konksu on tehniliselt võimatu. Seetõttu valiti konservatiivne lähenemine, alati laadida. See on teadlik arhitektuuriline otsus, mitte viga: plugin ohverdab jõudluse garanteeritud funktsionaalsuse nimel. Optimeerimise koorem lükatakse saidi arendaja õlule.

Kas vorm läheb katki pärast globaalse laadimise keelamist?

Ei, kui taastad skriptid hoolikalt vajalikel lehtedel. Vorm kaotab AJAX-i kaudu saatmise ja kliendipoolse valideerimise ainult lehtedel, kus skripte ei ole kaasatud. Seepärast on 2. samm (skriptide taastamine) kohustuslik, ära piirdu ainult WPCF7_LOAD_JS = false seadmisega. Kontrolli väljakutsete järjekorda: wpcf7_enqueue_scripts() peaks tulema enne wp_head(), mitte pärast. Ja veendu, et reCAPTCHA ei läheks vastuollu edasilükatud laadimisega.

Kas konstantide meetod töötab CF7 6.x versiooniga?

Jah, WPCF7_LOAD_JS ja WPCF7_LOAD_CSS konstandid on täielikult toetatud praeguses versioonis 6.1.6 (vaata ametlikku versioonilogi). Kogu plugina ajaloo vältel, versioonist 3.9 kuni praeguse 6.x-ni, ei ole neid konstante kunagi aegunuks kuulutatud. See on kõige stabiilsem ja dokumenteeritum meetod laadimise haldamiseks.

Mis siis, kui mul on mitu vormi eri kohtades?

Kui vormid on eri lehtedel laiali sisus olevate lühikoodide kaudu (mitte mallides), on ametlik mallidega meetod ebamugav. Kasuta kas lazy-cf7-assets (3. meetod) või Conditionally Load CF7 pluginat: see lisab administraatori paneelile seadistuse, millistel lehtedel/postitüüpidel skripte laadida, ja töötab ilma koodi muutmiseta.

Kolm koodirida kümnete päringute vastu

Probleem „CF7 laadib skripte igal pool" on eksisteerinud täpselt sama kaua kui plugin ise ning 10+ aasta jooksul pole arendaja vaikimisi käitumist muutnud, sest see on kompromiss lihtsuse ja jõudluse vahel. Aga kompromiss, mitte otsus.

Kõige ohutum tee on ametlik meetod konstantide ja mallidega. See eemaldab plugina skriptid ja stiilid kõigilt lehtedelt, välja arvatud need, kus neid vaja on, ega läki uuenduste käigus katki. Kui sinu sait kasutab kaasaegset komplekteerijaga töövoogu, vaata lazy-cf7-assets poole. Kui vajad midagi kiiret ja ilma malle muutmata, annab edasilükkamine clean_url konksu kaudu sulle mõõdikute paranemise juba täna.

Kontrolli oma saiti PageSpeed Insights kaudu enne ja pärast, blokeerivate päringute arvu vähendamine 1-2 ühiku võrra ning 10-30 KB säästmine lehe kohta võib tõsta jõudlusskoori 2-5 punkti võrra, eriti mobiilseadmetes.