
⚡ Kuidas lisada defer ja async WordPressi skriptidele failis function.php
Lehed laadivad aeglaselt, Google PageSpeed Insights näitab oranže hoiatusi ja klient küsib: „miks sait on aeglane?" Üheksal juhul kümnest on algpõhjuseks JavaScript, mis blokeerib renderdamise. Brauser jõuab <script>-sildini, peatab DOM-i ehitamise, laeb ja käivitab skripti ning alles seejärel jätkab. Kaasaegsel saidil, kus on kümmekond pistikprogrammi, muutub see viivitus sekunditeks.
WordPress ei pakkunud pikka aega standardset viisi skriptide laadimise juhtimiseks. Arendajad tantsisid ümber lahenduste: filtreerisid script_loader_tag-i, lappisid väljundit läbi clean_url-i või kirjutasid isegi kohandatud läbijaid WP_Scripts-ile. Kuid WordPressi 6.3 väljalaskega muutus olukord radikaalselt ja nüüd on meil puhas, toetatud viis lisada igale skriptile defer või async ilma ühegi häkita.
Allpool on kaks töötavat meetodit: kaasaegne natiivne lähenemine (WP 6.3+) ja tõestatud script_loader_tag filter (WP 4.1+). Mõlemat on testitud reaalsetes projektides, mõlemad säilitavad sõltuvuste järjekorra terviklikkuse.
💡 Kiirülevaade:
- Mõista erinevust
deferjaasyncvahel ning millal kumba kasutada, see määrab, kas funktsionaalsus pärast optimeerimist katki läheb - Kasuta WordPress 6.3+ natiivset meetodit
wp_enqueue_script()kaudu koosstrategyparameetriga, kõige puhtam lähenemine, mis säilitab käivitamise järjekorra - Kui sait töötab versioonil alla 6.3, rakenda
script_loader_tagfiltrit koos käepidemete massiiviga, see töötab alates WordPress 4.1-st - Mitme skripti puhul kogu käepidemed massiivi ja tsükkel läbi selle, üks filter kõigile skriptidele kopeeri-kleebi asemel
Mis on defer ja async ning millal neid kasutada
Kui brauser kohtab tavalist <script> silti, teeb see järjest kolm asja: peatab HTML-i parsimise, laeb skripti, käivitab selle. Alles seejärel naaseb HTML-i juurde. Lehel, kus <head>-is on viis skripti, tähendab see, et kasutaja näeb valget ekraani seni, kuni viimane kommentaariplugin laeb, kuigi postitus ise oleks võinud juba ammu renderduda.
Atribuudid defer ja async lahendavad selle probleemi, kuid töötavad erinevalt:
Atribuut | Millal laeb | Millal käivitub | Käivitamise järjekord |
|---|---|---|---|
(puudub) | Blokeerib parsimise kohe | Kohe pärast laadimist | DOM-i järjekorras |
| Paralleelselt parsimisega | Pärast DOM-i täielikku laadimist | DOM-i järjekorras |
| Paralleelselt parsimisega | Kohe pärast laadimist | Kes esimesena laeb |
Defer on tööhobune enamiku stsenaariumide jaoks. Skript laeb paralleelselt HTML-iga ja käivitub alles siis, kui DOM on täielikult ehitatud. Järjekord säilib: skript A käivitub enne skripti B, isegi kui B laadis kiiremini. See on kriitiline jQuery ja kõige selle jaoks, mis sellest sõltub.
Async on tööriist sõltumatutele skriptidele. Analüütika, reklaamid, sotsiaalmeedia vidinad: nad ei vaja DOM-i, nad ei hooli järjekorrast, nad peavad lihtsalt käivituma niipea kui võimalik. Aga kui paned async skriptile, mis sõltub jQuery-st, saad tõenäoliselt vea $ is not defined.
Lihtne reegel: skript sõltub teistest skriptidest või DOM-ist → defer. Skript on täiesti autonoomne → async. Kahtluse korral alusta alati defer-ist.
Meetod 1: Natiivne WordPress 6.3+ lähenemine
Alates 2023. aasta juulist töötab WordPressi tuumas uus mehhanism. Funktsioonid wp_register_script() ja wp_enqueue_script() said ülekoormatud viienda parameetri $args, massiivi, kus saab määrata laadimisstrateegia. Ei mingeid filtreid, stringimaagiat ega riski sõltuvuste järjekorda lõhkuda.
Põhisüntaks defer jaoks:
1 wp_enqueue_script( 2 'my-js-handle', 3 get_template_directory_uri() . '/js/my-script.js', 4 array('jquery'), 5 '1.0.0', 6 array( 7 'strategy' => 'defer', 8 'in_footer' => true, 9 ) 10 );
async jaoks, sama mehaanika:
1 wp_enqueue_script( 2 'google-analytics', 3 'https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX', 4 array(), 5 '1.0.0', 6 array( 7 'strategy' => 'async', 8 'in_footer' => false, 9 ) 10 );
in_footer võti massiivi sees töötab samamoodi nagu vana tõeväärtusparameeter: true paneb skripti jalusesse, false <head>-i. defer puhul määrad tavaliselt true (skript ootab niikuinii DOM-i, pole mõtet seda vara laadida), async puhul sobib see, mis töötab.
Natiivse meetodi peamine eelis on see, et tuum ise kontrollib sõltuvuspuud. Kui skript A defer-iga sõltub skriptist B ja B on registreeritud ilma strateegiata (blokeeriv), ei lõhu WordPress teie saiti: see alandab automaatselt skripti A strateegia blokeerivaks. script_loader_tag kasutamisel sul see kaitse puudub, filter lihtsalt sisestab atribuudi sõltuvusi vaatamata.
Oluline: $args massiiv ilmus WordPress 6.3-s. Kui teema või plugin peab töötama madalamatel versioonidel, kasuta meetodit 2 või lisa kontroll:
1 if ( version_compare( $GLOBALS['wp_version'], '6.3', '>=' ) ) { 2 // native method 3 } else { 4 // script_loader_tag filter 5 }
Meetod 2: script_loader_tag filter (WordPress 4.1+)
Kui sait töötab versioonil alla 6.3 või pead säilitama tagasiühilduvuse, rakenda tõestatud script_loader_tag filtrit. See on olemas alates WordPress 4.1-st ja töötab endiselt veatult.
Filter käivitub vahetult enne <script> sildi HTML-i väljastamist, saad valmis sildi stringi, skripti käepideme ja failitee ning saad asendada src väärtusega defer="defer" src või async="async" src.
Üksik skript defer-iga:
1 function add_defer_to_my_script($tag, $handle) { 2 if ( 'my-js-handle' !== $handle ) { 3 return $tag; 4 } 5 return str_replace( ' src', ' defer="defer" src', $tag ); 6 } 7 add_filter('script_loader_tag', 'add_defer_to_my_script', 10, 2);
Kood läheb aktiivse teema functions.php faili või, õigemini, eraldi lõigupluginasse nagu Code Snippets või WPCode. Kui paned selle alamteema functions.php-sse, muutuvad skriptid teema vahetamisel uuesti blokeerivaks ja sa ei märka seda kohe.
Skripti käepide on esimene parameeter, mille sa edastasid wp_register_script()-ile või wp_enqueue_script()-ile. See on see, mis ilmub if tingimusse. Ära arva käepidet, ava plugina või teema lähtekood ja leia wp_enqueue_script väljakutse.
Defer ja async mitmele skriptile
Ühe filtri lisamine skripti kohta on tee puhutud functions.php ja kopeeri-kleebi vigadeni. Õige lahendus: käepidemete massiiv ja üks filter koos tsükliga.
1 function add_defer_to_scripts($tag, $handle) { 2 $scripts_to_defer = array( 3 'my-js-handle', 4 'another-handle', 5 'third-party-lib', 6 ); 7 8 foreach ( $scripts_to_defer as $defer_script ) { 9 if ( $defer_script === $handle ) { 10 return str_replace( ' src', ' defer="defer" src', $tag ); 11 } 12 } 13 return $tag; 14 } 15 add_filter('script_loader_tag', 'add_defer_to_scripts', 10, 2);
async jaoks muutuvad ainult atribuut ja massiivi nimi:
1 function add_async_to_scripts($tag, $handle) { 2 $scripts_to_async = array( 3 'google-tag-manager', 4 'facebook-pixel', 5 'hotjar', 6 ); 7 8 foreach ( $scripts_to_async as $async_script ) { 9 if ( $async_script === $handle ) { 10 return str_replace( ' src', ' async="async" src', $tag ); 11 } 12 } 13 return $tag; 14 } 15 add_filter('script_loader_tag', 'add_async_to_scripts', 10, 2);
Mõlemat filtrit saab ühendada samaaegselt, defer sinu skriptidel, async kolmandate osapoolte jälgijatel. Need töötavad iseseisvalt ega lähe vastuollu.
Praktiline näide: Google Maps API
Google Maps on klassikaline kandidaat defer jaoks. Kaart on tavaliselt kontaktide lehe jaluses, skript tõmbab 100+ KB ja kasutaja ei vaja kaarti kohe. Pealegi, API ise ei sõltu teistest lehe skriptidest, ideaalne juhtum.
Ühenda ja lükka edasi:
1 // theme's functions.php 2 function enqueue_google_maps() { 3 if ( ! is_page('contacts') ) { 4 return; 5 } 6 7 wp_enqueue_script( 8 'google-maps-api', 9 'https://maps.googleapis.com/maps/api/js?key=YOUR_API_KEY', 10 array(), 11 null, 12 array( 13 'strategy' => 'defer', 14 'in_footer' => true, 15 ) 16 ); 17 } 18 add_action('wp_enqueue_scripts', 'enqueue_google_maps');
Sama tulemus script_loader_tag kaudu:
1 function add_defer_to_google_maps($tag, $handle) { 2 if ( 'google-maps-api' !== $handle ) { 3 return $tag; 4 } 5 return str_replace( ' src', ' defer="defer" src', $tag ); 6 } 7 add_filter('script_loader_tag', 'add_defer_to_google_maps', 10, 2);
Pärast kummagi variandi paigaldamist kontrolli kindlasti kaarti kontaktide lehel. Ava brauseri konsool (F12), veendu, et JavaScripti vigu pole ja et kaart renderdus õigesti. Kui saad vea nagu initMap is not a function, tähendab see, et sinu lähtestamisskript tuleb samuti märkida defer-iga ja paigutada rangelt pärast API ühendust.
Kuidas kontrollida, kas defer ja async töötavad
Pärast juurutamist tuleb kontrollimine. Ilma selleta sa ei tea, kas optimeerimine töötas või on lihtsalt surnud kood.
Ava lehe lähtekood (Ctrl+U) ja leia oma skriptid. <script> sildil peaksid olema atribuudid:
1 <script defer="defer" src="/wp-content/themes/my-theme/js/my-script.js"></script>
Kui atribuute pole, kontrolli, kas filtri käepide vastab tegelikule skripti käepidemele. Levinud viga: wp_enqueue_script-is on käepide my-plugin-frontend, kuid filtris on my_plugin_frontend. Sidekriips versus alakriips ja filter jätab skripti vaikselt vahele.
Viimane lihv, Google PageSpeed Insights või Lighthouse arendajatööriistade Audits vahekaardil. Jaotis „Eliminate render-blocking resources" peaks näitama paranemist. Konkreetne võit sõltub skriptide arvust ja suurusest, kuid tüüpilise WordPressi saidi puhul, kus on 5-7 pistikprogrammi, on blokeeriva JavaScripti 40-60% vähenemine saavutatav tulemus.
⁉️🤔 Korduma kippuvad küsimused
Kas ma saan kasutada nii defer kui async ühel skriptil?
Ei. Kui määrad mõlemad atribuudid korraga, ignoreerib brauser
defer-i ja käivitab skripti kuiasync. See käitumine on HTML-i spetsifikatsiooni sisse ehitatud,asyncon alati prioriteetne. Vali üks selle põhjal, kas käivitamise järjekord on oluline.
Mida teha, kui pärast defer lisamist skript lakkas töötamast?
Tõenäoliselt eeldab skript, et DOM pole veel ehitatud ja üritab manipuleerida elementidega, mida käivitamise hetkel pole olemas. Asenda
deferstandardse blokeeriva laadimisega selle konkreetse skripti jaoks. Või mähi skripti koodDOMContentLoadedsisse, siis saab see töötadadefer-iga vigadeta. Teine variant on eelistatum: säilitad optimeerimise ja parandad ühilduvuse.
Mis vahe on defer ja skripti jalusesse viimise vahel wp_enqueue_script abil koos $in_footer = true?
$in_footer = truelihtsalt liigutab<script>sildi<head>-ist<body>lõppu. Skript blokeerib endiselt renderdamist, lihtsalt hiljem.deferlaeb paralleelselt HTML-i parsimisega ja käivitub rangelt pärast DOM-i ehitamist. Kombineeritud kasutamine (in_footer => true+strategy => 'defer') annab maksimaalse efekti: jalusesse pandud skript ei viivita esimest renderdust ja defer garanteerib, et see ei blokeeri ka lõplikku renderdamist.
Kas ma peaksin uuendama WordPressi versioonile 6.3 ainult natiivse meetodi pärast?
Kui sait on versioonil 6.2 või vanem, tasub uuendada mitte ainult
strategypärast. WordPress 6.3 sulges kümneid turvaauke ja tõi tuuma jõudluse paranemisi. Aga kui uuendamine on mingil põhjusel võimatu, töötabscript_loader_tagfilter absoluutselt usaldusväärselt alates versioonist 4.1, mis anti välja 2014. aastal. Sa ei kaota seda kasutades midagi.
Aga jQuery, defer või jätta nii nagu on?
jQuery peaks laadima
defer-iga, kui kõik sõltuvad skriptid on samuti märgituddefer-iga. Probleem on selles, et WordPressi pluginad haldavad oma skriptide atribuute äärmiselt harva. Kui paned jQuery-ledefer-i, samal ajal kui kontaktvormi plugin ühendab oma skripti ilma atribuutideta, käivitab brauser plugina enne jQuery-t ja vorm läheb katki. Praktiline nõuanne: alustadefer-iga oma teema skriptidele. Ära puuduta jQuery-t enne, kui oled testinud iga pluginat saidil.
Mida panna tootmissaidile aastal 2026
Kui server töötab WordPress 6.3 või uuemaga, ainult natiivne meetod. Puhas kood, kaitse sõltuvuskonfliktide eest, tuuma tugi. Alusta defer-iga kõigile teema skriptidele ja kriitiliselt olulistele pistikprogrammidele; reserveeri async analüütikale ja kolmandate osapoolte vidinatele.
Kui versioon on alla 6.3, script_loader_tag filter koos käepidemete massiiviga. See on töötanud aastakümne, pole midagi lõhkuda. Ainus, mida see teha ei suuda, on automaatselt kontrollida sõltuvuspuud, seega lisa skripte massiivi ükshaaval ja kontrolli saiti pärast iga lisamist.
Ja mis kõige tähtsam: ükski meetod ei asenda skriptide endi auditeerimist. Kui galeriiplugin ühendab 15 faili, et näidata vaid kolme pilti, ei aita ei defer ega async radikaalselt. Laadimise optimeerimine algab küsimusest „kas seda skripti üldse on vaja" ja alles seejärel „kuidas seda laadida".
🔗 Ametlik WordPress 6.3 dokumentatsioon, Script Loading Strategies



