Teie sait laadib 4 sekundit ja külastaja lahkub. Kõlab tuttavalt?

Google'i 2023. aasta uuringu kohaselt suureneb lahkumise tõenäosus 32%, kui laadimisaeg kasvab 1 sekundilt 3 sekundile. Üks peamisi aegluse põhjuseid, mis sageli tähelepanuta jääb, on ülemäärane HTTP-päringute hulk. Need ei paista silma nagu rasked pildid või kehv majutus, kuid neid koguneb kümnete kaupa ja kokku kulutavad nad sekundeid.

Vaatame üle, mis need päringud on, kuidas neid GTmetrixi koskdiagrammi abil leida ja mis kõige tähtsam, kuidas nende arvu vähendada ilma saidi funktsionaalsust kahjustamata.

💡 Kiirülevaade:

• Ava GTmetrix, kleebi oma saidi URL ja mine vahekaardile Waterfall, et näha iga päringut koos selle suuruse ja laadimisajaga
• Filtreeri päringuid kaustade plugins ja themes järgi, et leida pluginad, mis laadivad skripte asjatult kõigil lehtedel
• Mine läbi 5 kontrollpunkti: mittevajalikud pildid, kombineerimata CSS/JS, globaalse laadimisega pluginad, rasked pluginad ja puuduv laisklaadimine
• Pärast muudatuste tegemist käivita test uuesti ja võrdle päringute arvu enne ja pärast

Mis on HTTP-päringud ja miks need teie saiti aeglustavad

Kui brauser avab lehe, ei saa ta korraga valmis pilti kätte. Ta vajab HTML-skeletti, stiilifaile, iga skripti, fonte, pilte ja iga elemendi jaoks saadab brauser serverile eraldi HTTP-päringu.

Osa päringuid läheb teie serverisse (sisemised: pildid meediakogust, teema, pluginad). Teised lähevad välistele teenustele (Google Analytics, YouTube'i manused, reklaamiskriptid). Brauser paneb need järjekorda ja laadib.

Seos on lihtne: rohkem päringuid tähendab pikemat laadimisaega. Kuid kõik päringud pole võrdsed. Pisike jälgimisskript laadib 20 ms, samas kui optimeerimata 500 KB pilt võib rippuda pool sekundit. Seega eesmärk pole lihtsalt „arvu vähendada", vaid eemaldada mittevajalikud ja muuta ülejäänud kergemaks.

Praktikas on erinevus märgatav: portfooliosait puhtal teemal teeb 18 päringut ja avaneb silmapilkselt. Suur uudisteportaal nagu New York Times teeb üle 200 päringu, millest pooled on reklaami- ja jälgimisskriptid. Teie sait on kuskil vahepeal ja seda arvu saab vähendada.

Kuidas HTTP-päringuid analüüsida: koskdiagramm GTmetrixis

Kõige selgem viis HTTP-päringute nägemiseks on koskdiagramm (kaskaad). See näitab iga päringut eraldi reana: kust see tuleb, kui palju see kaalub, millal see laadima hakkas ja kui kaua aega võttis.

Tööriistad, mis suudavad koskdiagramme kuvada:

• Sisseehitatud Chrome DevTools (vahekaart Network), tasuta, kuid ainult teie brauseri jaoks
• GTmetrix, tasuta tase, testimine erinevatest asukohtadest, selge liides
• Pingdom Tools, sarnane GTmetrixile, erinevad testimispunktid
• WebPageTest, maksimaalne detailsus, kuid alustamiseks keerulisem

Vaatame näitena GTmetrixi. Kleebi URL, käivita test. Tulemustes leiad vahekaardi Waterfall, mis ongi kaskaad:

Diagramm ise näeb välja selline:

Mida veerud tähendavad:

• URL, faili asukoht. See näitab, milline plugin või teema päringu lisas
• Domeen, sinu server või väline. Näed kohe, kui palju laaditakse väljastpoolt
• Suurus, faili kaal. Rasked päringud mõjutavad kiirust tugevamalt
• Ajajoon, millal päring algas ja kui kaua see kestis. Suurus pole ainus oluline asi: ahela alguses olev fail blokeerib kõik, mis tuleb pärast seda

Klõpsa diagrammi kohal otsinguväljale ja sisesta wp-content/plugins, et näha ainult pluginapäringuid. Allolevas näites lisab Lightweight Social Fonts plugin fondipäringu fontello.woff suurusega 22,9 KB:

Kui filtreerid themes järgi, näed teemade päringuid. Näiteks GeneratePress teeb ainult 4 päringut, mis on kerge teema puhul hea näitaja:

Mine nimekiri läbi ja küsi endalt: „Kas see plugin peab tõesti igal lehel laadima?" Sageli on vastus ei. Mida sellega ette võtta, sellest räägime järgmisena.

5 Viisi HTTP-päringute vähendamiseks WordPressis

Pärast koskanalüüsi on sul käes päringute nimekiri. Nüüd konkreetsetest sammudest nende vähendamiseks.

1. Eemalda mittevajalikud ja ettevalmistamata pildid

Iga pilt = üks HTTP-päring. Kui lehel on 15 pilti ja neist 5 on dekoratiivsed või duplikaadid, on see 5 päringut, mille saad ilma sisu kaotamata eemaldada. Oluliste piltide puhul kehtib teine reegel: tihenda ja muuda suurus vastavaks kuvamõõtmetele. 2500 px pilt, mis on paigutatud 700 px laiusesse plokki, laadib 5 korda rohkem andmeid kui vaja.

Praktikas aitab kombinatsioon: käsitsi ülevaatus (eemalda mittevajalik) + tihendusplugin. Praeguste valikute hulgas on ShortPixel, Imagify, Smush. Need tihendavad pilte meediateeki üleslaadimisel ja suudavad uuesti tihendada ka olemasolevaid.

2. Kombineeri CSS ja JavaScript

Teema ja iga plugin lisavad oma stiili- ja skriptifailid. Kui sul on aktiivne teema, 10 pluginat ja paar välist teenust, võib kergesti koguneda 30-40 eraldi CSS/JS-faili. Igaüks neist nõuab eraldi HTTP-päringut.

Seda tehnikat nimetatakse konkatenatsiooniks (kombineerimine) ja tavaliselt käib sellega kaasas minifitseerimine (tühikute ja kommentaaride eemaldamine koodist). Enamik jõudluspluginaid teeb mõlemat:

• WP Rocket, tasuline plugin, kombineerib ja minifitseerib CSS/JS-i mõne klõpsuga
• Autoptimize, tasuta, ainult konkatenatsioon ja minifitseerimine

Oluline: pärast kombineerimise sisselülitamist mine oma saidi peamised lehed läbi ja veendu, et kujundus pole katki läinud. Mõnikord lähevad skriptid liitmisel konflikti, sel juhul jätad selle konkreetse faili kombineerimisest välja.

3. Takista pluginatel laadimast seal, kus neid vaja pole

Kontaktivorm asub ainult kontaktilehel. Kuid selle CSS ja JS laadivad sageli kogu saidil, mis tähendab 2-3 lisapäringut igal lehel, kus vormi pole. Näiteks Contact Form 7 laadib skripte globaalselt vaikimisi.

Kui plugin seda võimaldab, on kaks teed:

• Asenda see optimeerituma alternatiiviga, mis ei laadi ressursse globaalselt
• Jäta plugin alles, kuid halda skriptide laadimist Perfmattersi kaudu, millel on skriptihaldur, mis võimaldab plugina CSS-i/JS-i keelata kõigil lehtedel, välja arvatud seal, kus seda tegelikult kasutatakse

Tulemus: samad 2-3 päringut, kuid ainult kontaktilehel, mitte kogu saidil.

4. Asenda rasked pluginad kergemate alternatiividega

Pärast koske filtreerimist märksõnaga plugins näed, millised pluginad genereerivad kõige rohkem päringuid. Kui üks plugin lisab 8 skripti ja stiili, samas kui selle alternatiiv saab hakkama kahega, vähendab vahetamine 6 HTTP-päringut.

Näiteid asendustest praktikast:

• Revolution Slider (raske) → kerge kaaneblokk teemast või MetaSlider
• Leheehitaja kümnete skriptidega → loomulik Gutenbergi plokiredaktor
• Sotsiaalmeedia plugin väliste API-päringutega → staatilised lingiikoonid

Kontrolli iga pluginat koske nimekirjast: kas seda üldse kasutatakse? Kui pluginat pole üle aasta uuendatud või funktsionaalsust pole vaja, kustuta see täielikult.

5. Luba laisklaadimine

Laisklaadimine lükkab edasi piltide ja iframe'ide laadimise, mis jäävad nähtavast ekraanialast allapoole. Külastaja avab lehe ja laadib ainult see, mida ta näeb. Ülejäänu tõmmatakse sisse kerimise käigus.

Alates WordPressi versioonist 5.5 lisatakse piltidele automaatselt atribuut loading="lazy". See on põhistsenaariumi jaoks piisav. Kui vajad agressiivsemat laisklaadimist (iframe'ide, taustapiltide, videote jaoks), kasuta Perfmattersit, WP Rocketit või tasuta LazyLoad by WP Rocket pluginat.

Video: WordPressi HTTP-päringud 5 minutiga

Lühike video teemal, alates diagnoosimisest kuni päringute vähendamiseni ilma pluginateta:

⁉️🤔 Korduma kippuvad küsimused

Kui palju HTTP-päringuid on WordPressi puhul normaalne?

Universaalset numbrit pole. Puhas sait kerge teemaga ja 5-7 pluginaga mahub 25-40 päringu sisse. Leheehitaja, reklaamiskriptide ja tosina pluginaga sait võib teha 80-120 päringut. Ära keskendu absoluutarvule, vaid trendile: kui oli 90 ja sai 55, on see hea tulemus.

Kas välised päringud (Google Fonts, Analytics) mõjutavad kiirust?

Mõjutavad küll, aga erinevalt. Väline päring Google Fontsi laadib 1-2 päringut, kuid need käivad läbi Google'i CDNi ja laadivad kiiresti. Peamine probleem on renderduse blokeerimine: kuni font pole laadinud, ei pruugi brauser teksti kuvada. Lahendus: laadi fondid eelnevalt preload-atribuudiga või majuta fonte lokaalselt.

Kas kogu CSS ja JS tuleb tingimata ühte faili kokku panna?

Mitte alati. Kõigi skriptide ühte faili kombineerimine annab ühe päringu, kuid suur fail laadib kauem. Kaasaegne HTTP/2 suudab laadida mitut faili paralleelselt, nii et 3-4 faili à 30 KB võivad laadida kiiremini kui üks 120 KB fail. Optimaalselt kombineeri kriitiline CSS (see, mida on vaja esimese ekraani kuvamiseks) ja jäta mittekriitilised skriptid defer-atribuudiga eraldi.

Mida teha, kui paigutus laguneb pärast CSS-i kombineerimist?

Välista probleemne fail kombineerimisest. WP Rocket ja Autoptimize võimaldavad lisada skripti või stiili URL-i välistuste nimekirja. Pärast seda tee test uuesti. Ühe faili kaotamine 15 päringu hulgast on vaevu märgatav.

Kas päringuid saab vähendada ilma pluginateta?

Saab. Skriptide käsitsi deregistreerimine functions.php kaudu annab täieliku kontrolli, kuid eeldab WordPressi hookide mõistmist. Enamiku saidiomanike jaoks on WP Rocket või Perfmatters lihtsam ja turvalisem: need ei lase sul tööks kriitilist skripti keelata.

Aeg oma päringud korda teha

HTTP-päringud pole asi, mille sa ühe korra korda teed. Paigalda uus plugin, vaheta teemat, lisa reklaamiskript ja uued päringud tekivad. Iga paari kuu tagant mine GTmetrixi, ava Waterfall ja võrdle sellega, mis sul eelmisel korral oli.

Kui sa ei tea praegu, mitu päringut su sait teeb, ava GTmetrix, kleebi URL ja klõpsa „Start Test". Minuti pärast näed tegelikku pilti. Seejärel järgi selle artikli samme. Iga eemaldatud päring toob su saidi lähemale 1-2 sekundiga laadimisele.