
Sisukord
Iga WordPress projekt kogub aja jooksul pluginaid. Üks lisati testimiseks ja jäi. Teine lahendas ühekordse probleemi ja pole enam vajalik. Kolmas laadib oma CSS-i ja JS-i kõikjal, kuigi seda kasutatakse ühel lehel. Kuue kuu pärast on aktiivsete pluginate nimekiri pikk ja keegi ei mäleta täpselt, miks pool neist seal on.
Audit ei ole ühekordne tegevus – see on regulaarne praktika. Aga isegi ühekordne läbivaatus toob tavaliselt esile üllatavalt palju parandatavat.
Kaks eraldi probleemi – liigsed pluginad ja valesti laaditud skriptid
Need on erinevad probleemid, mis nõuavad erinevat lähenemist.
Liigne plugin – plugin, mida ei kasutata üldse, või mille funktsionaalsust saaks lahendada koodiga (nagu oleme näidanud SVG üleslaadimise, redirectide ja custom väljade artiklites).
Valesti laaditud skript – plugin on vajalik, aga selle skriptid/stiilid laadivad kõikjal, mitte ainult seal, kus neid tegelikult kasutatakse.
Teine probleem on levinum ja sageli suurema mõjuga jõudlusele, sest see kordub igal lehe laadimisel, sõltumata sellest, kas plugin ise on “hea” või “halb”.
Näide 1 – reCAPTCHA ainult kontaktvormi lehtedel
Vormipluginad (Gravity Forms, Contact Form 7, WPForms) laadivad reCAPTCHA skripti tihti globaalselt – “igaks juhuks, kui vorm kuskil on”. Reaalsuses on vorme tavaliselt 2-3 lehel kogu saidil.
Audit samm: GTmetrix Waterfall või Chrome DevTools Network → otsi recaptcha või google.com/recaptcha päringuid lehtedel, kus vormi pole. Kui leiad – on aeg tingimuslik laadimine seadistada.
add_action('wp_enqueue_scripts', 'hnd_recaptcha_ainult_vormidel', 20);
function hnd_recaptcha_ainult_vormidel() {
$vormi_lehed = array('kontakt', 'pakkumine', 'registreeru');
if ( ! is_page($vormi_lehed) ) {
wp_dequeue_script('google-recaptcha');
wp_dequeue_script('gforms_recaptcha');
}
}
Tulemus: reCAPTCHA (~50-80 KB koos Google’i väliste skriptidega) laadib ainult seal, kus see reaalselt on vajalik – mitte blogipostituses, mitte avalehel, mitte tootekataloogis.
Näide 2 – WooCommerce skriptid teadlikult üldistel lehtedel keelatud
Oleme Cart Fragments artiklis juba käsitlenud üht WooCommerce jõudlusprobleemi. Laiem põhimõte on sama: WooCommerce laeb hulga skripte, mida vajatakse ainult poe kontekstis.
add_action('wp_enqueue_scripts', 'hnd_wc_scripts_audit', 99);
function hnd_wc_scripts_audit() {
if ( ! function_exists('is_woocommerce') ) {
return;
}
$on_shop = is_woocommerce() || is_cart() || is_checkout() || is_account_page();
if ( $on_shop ) {
return; // Kõik WooCommerce skriptid vajalikud
}
// Teadlik nimekiri skriptidest, mida mittepoodi lehtedel EI vajata
$wc_scripts_to_remove = array(
'wc-cart-fragments',
'wc-add-to-cart',
'wc-add-to-cart-variation',
'wc-single-product',
'selectWoo',
'wc-country-select',
);
foreach ($wc_scripts_to_remove as $script) {
wp_dequeue_script($script);
wp_deregister_script($script);
}
}
Iga eemaldatud skript on üks vähem HTTP päring ja üks vähem JavaScript’i, mida brauser peab parsima blogipostituses või avalehel.
Näide 3 – Plugin CSS/JS ainult lehtedel, kus plugin päriselt kasutusel
See on üldistatav muster, mis kehtib peaaegu iga pluginaga. Kasuta Perfmatters Script Manager’it (visuaalne) või koodi (paindlikum) selleks, et laadida plugina ressursid ainult sinna, kus plugin funktsionaalsust pakub.
Näide – galeriiplugin, mis laadib CSS/JS ainult postitustel/lehtedel, kus shortcode või blokk on kasutusel:
add_action('wp_enqueue_scripts', 'hnd_galerii_plugin_conditional', 20);
function hnd_galerii_plugin_conditional() {
global $post;
if ( ! is_a($post, 'WP_Post') ) {
return;
}
// Kontrolli, kas leht sisaldab galerii shortcode'i
$has_gallery = has_shortcode($post->post_content, 'minu_galerii')
|| has_block('minu-plugin/galerii', $post);
if ( ! $has_gallery ) {
wp_dequeue_style('galerii-plugin-style');
wp_dequeue_script('galerii-plugin-script');
}
}
has_shortcode() ja has_block() on WordPress’i sisseehitatud funktsioonid, mis kontrollivad postituse sisu enne renderdamist – ideaalsed just sellise tingimusliku loogika jaoks.
Perfmatters Script Manager – visuaalne audit
Kui koodi kirjutamine iga plugina jaoks tundub liiga aeganõudev, lahendab Perfmatters Script Manager sama probleemi visuaalselt.
Kuidas kasutada:
- Ava mis tahes leht saidil koos Perfmatters’i debug moega
- Script Manager näitab kõiki laaditud skripte ja stiile sellel lehel
- Iga skripti juures saab valida “Disable” (kõikjal) või “Enable on” (konkreetsetel lehtedel/postitustel)
See on kiireim viis leida “üllatusi” – skripte, mille olemasolust polnud teadlik, või mis laadivad kohtades, kus neid ei oodanud.
Tüüpilised leiud auditis:
- Sotsiaalmeedia jagamisnupud, mis laadivad kõikjal, kuigi kasutatakse ainult blogis
- Slaideri pluginad, mis laadivad kõikjal, kuigi slaidereid on ainult avalehel
- Vana plugin, mis on deaktiveeritud aga mille jäänuk-kood ikka laadib (harv, aga juhtub)
- Teema demo andmetega kaasa tulnud skriptid, mida keegi kunagi ei eemaldanud
Liigsete pluginate tuvastamine
Peale skriptide auditi tasub vaadata ka pluginate nimekirja tervikuna:
Query Monitor plugin – näitab, millised pluginad teevad kõige rohkem andmebaasipäringuid ja kui kaua nende PHP kood täidab. Aeglane plugin ei pruugi laadida palju JS/CSS-i, aga võib ikkagi PHP tasandil TTFB-d kahjustada.
Küsimused iga plugina kohta:
- Millal seda viimati kasutati? (Kui ei mäleta, on see kahtlane märk)
- Kas see funktsionaalsus on lahendatav 10-realise koodiga? (SVG üleslaadimine, lihtsad redirectid, custom väljad – kõik need näited oleme läbi käinud)
- Kas kaks pluginat teevad sama asja? (Levinud – nt kaks SEO pluginat korraga, mis konfliktis)
- Kas plugin on aktiivselt hooldatud? (WordPress.org näitab viimast uuenduskuupäeva – üle aasta vana on riskantne)
Audit rutiin – kord kvartalis
1. Perfmatters Script Manager läbivaatus – ava peamised lehetüübid (avaleht, blogipostitus, tootelehekülg, kontaktileht), vaata mis laadib igal.
2. Pluginate nimekirja läbivaatus – iga plugina juures küsi eelmainitud küsimused.
3. GTmetrix/PSI enne-pärast – dokumenteeri skoor enne muudatusi, võrdle pärast.
4. Testimine – iga eemaldatud/tingimuslikuks muudetud skripti järel testi, et funktsionaalsus säilib seal, kus vaja.
Kokkuvõte
Plugina ja skripti audit ei ole ühekordne “suur koristus” – see on distsipliin, mis tasub end ära regulaarse läbivaatusega. Väikesed muudatused (reCAPTCHA ainult vormidel, WooCommerce skriptid ainult poes, galeriiplugin ainult galeriidega lehtedel) kokku annavad märkimisväärse jõudlusvõidu.
Iga skript, mis laadib “igaks juhuks kõikjal”, on kiirus, mida sinu külastajad maksavad kinni – ilma, et nad sellest teaksid.
Seotud postitused
WordPress e-posti saatmine SMTP kaudu – miks vaikimisi ei tööta
WordPress wp_mail() ei ole usaldusväärne. Brevo ja Mailgun seadistus SMTP kaudu, SPF/DKIM/DMARC…
Mobiil-first indekseerimine – mida see tähendab praktikas
Google indekseerib su lehte mobiilse versiooni põhjal, mitte desktop versiooni. Levinud vead,…
Kolmanda osapoole skriptid – millal laadida, millal mitte
Kriitiline, oluline, valikuline – raamistik iga välise skripti jaoks. reCAPTCHA, YouTube embed,…
Kuidas lisada custom JS ainult ühele lehele
wp_enqueue_script tingimustega, defer vs async atribuudid ja wp_localize_script andmete…