Sinu sait on aeglane ja GTMetrix näitab 130+ HTTP-päringut lehe kohta?

See pole mingi abstraktne number raportist. Iga päring on brauseri kutse serverisse faili järele: skript, stiilileht, pilt või font. Mida rohkem päringuid, seda kauem vaatavad külastajad tühja ekraani. Portenti andmetel vähendab laadimisviivitus 0-lt 3 sekundile konversiooni 2,5%. Ja iga lisasekund pärast seda maksab veel 4,4%.

HTTP-päringute probleem ei ole nende olemasolus. Probleem on selles, et enamik WordPressi saite genereerib neid palju rohkem kui vaja. Allpool on viis konkreetset sammu, mis vähendavad päringute arvu ilma saiti nullist ümber kirjutamata.

💡 Kiirülevaade:

• Eemalda kasutamata pluginad ja teemad, mis tekitavad igal lehel lisapäringuid
• Optimeeri pilte: tihenda faile, eemalda kasutamata pildid, ühenda ikoonid sprite'ideks
• Liida CSS ja JavaScript 1-2 failiks ja luba minifitseerimine
• Seadista edasilükatud laadimine skriptidele, mis blokeerivad lehe renderdamist
• Luba vahemälu ja CDN, et naasvad külastajad ei laadiks kogu saiti uuesti

Samm 1. Korista üleliigne ära

Iga installitud plugin toob endaga faile kaasa. PHP, CSS, JavaScript: ükskõik milline neist tekitab lehe laadimisel HTTP-päringu. Kakskümmend pluginat tähendab ligi sada päringut juba käivitamisel, enne igasugust sisu.

Esimene asi, mida teha, on audit. Ava Pluginad → Installitud pluginad ja küsi endalt ausalt: millised on saidi toimimiseks kriitilised ja millised lihtsalt seisavad seal „igaks juhuks"? See SEO analüsaator, mille aasta tagasi installisid ja kaks korda avasid, on eemaldamise kandidaat. Sotsiaalikoonide plugin on samuti, kui oled lingid niikuinii juba jalusesse lisanud.

Omaette kategooria on pluginad, mis ühenduvad kolmandate osapoolte serveritega. Live-chat, voogedastusraadio, tõuketeavitused. Iga selline plugin loob täiendavaid väliseid HTTP-päringuid kolmandate osapoolte serveritesse. Kustuta kõik, milleta sait toimida saab. Vajad kord kuus? Installi üheks päevaks ja seejärel eemalda.

Sama reegel kehtib teemade kohta. Välimus → Teemad all hoia alles ainult oma aktiivne teema ja üks varukoopia (näiteks vaikimisi Twenty Twenty-Five). Kustuta ülejäänud.

Kui pluginat on vaja, kuid ainult konkreetsel lehel, laadi see valikuliselt. Asset CleanUp: Page Speed Booster teeb täpselt seda. See on tasuta plugin, millel on 100 000+ aktiivset installatsiooni ja hinnang 4,7 WordPress.org-is.

Plugin skannib lehe, näitab laaditud CSS- ja JS-failide loendit ning võimaldab keelata konkreetseid faile teatud lehtedel, postitüüpidel või üle kogu saidi. Vajad Contact Form 7 ainult kontaktlehel? Eemalda linnuke kõikjalt mujalt ja selle skriptid ei laadi seal, kus vormi ei kasutata.

🔗 Asset CleanUp WordPress.org-is

Samal ajal optimeeri ka oma andmebaasi. Pärast pluginade koristamist jäävad nende seaded ja kirjed tabelitesse alles ning need tuleks samuti eemaldada. Kontrolli ka katkisi linke: iga ümbersuunamine on täiendav HTTP-päring.

Et probleemi ulatust enne ja pärast selgelt näha, testi oma saiti GTMetrixis:

Esimene käik näitab lähtetaset: päringute arv, lehe kogumaht, laadimisaeg. Pärast iga sammu selles artiklis käivita test uuesti. Nii näed, millised muudatused andsid suurima mõju.

Samm 2. Optimeeri pildid

Pildid on keskmise WordPressi lehe suurim „raskus". HTTP Archive'i andmetel moodustavad pildid lauaarvutis umbes 44% lehe kogumahust. Ja iga pilt on HTTP-päring.

Alusta kasutamata failide eemaldamisest. Meedia → Kogu all filtreeri „Manuseta". Need on pildid, mis pole ühegi postitusega seotud. Kui neid ei kasutata teemas ega jaluses, kustuta need.

Järgmisena tuleb tihendamine. Pluginad nagu WP Compress teevad seda automaatselt: pildi üleslaadimisel läbib see pilveoptimeerija, tihendatakse ilma nähtava kvaliteedikaota ja teisendatakse WebP- või AVIF-vormingusse. Need vormingud on sama visuaalse kvaliteedi juures märgatavalt kergemad kui JPEG. Google'i andmetel vähendab WebP failimahtu keskmiselt 25-35% võrreldes JPEG-ga.

WP Compressil on 10 000+ aktiivset installatsiooni, hinnang 4,5 viiest ja üle 1,1 miljoni allalaadimise WordPress.org-is. Esimesed 100 pilti on tasuta, piisavalt, et erinevust näha.

🔗 WP Compress WordPress.org-is

Ainuüksi tihendamine ei vähenda HTTP-päringute arvu. Küll aga vähendab see iga faili mahtu, mis tähendab vähem aega selle edastamiseks. Koos teiste sammudega annab see märgatava kiiruse tõusu.

CSS-spraidid: üks fail kümne asemel

Kui sul on lehel kümmekond väikest ikooni (sotsiaalvõrgustikud, nooled, hinnangutärnid), laadib igaüks neist eraldi päringuna. CSS-sprait lahendab selle: kõik ikoonid ühendatakse üheks failiks ja CSS kuvab vajaliku fragmendi.

Toimimispõhimõte: viis pilti tähendab viit serveripäringut. Needsamad viis pilti üheks spraidiks ühendatuna tähendab ühte päringut. Veebitööriistad nagu CSS Sprite Generator saavad luua sprite sulle. Iga ikooni background-position seadistamiseks on vaja algteadmisi CSS-ist.

Märkus: kui sinu server toetab HTTP/2, laaditakse failid ühe ühenduse piires asünkroonselt. Sel juhul on spraitide sääst vähem märgatav. Kuid praktikas laadib kümmekond ikooni ühes failis siiski kiiremini kui kümme eraldi faili.

Samm 3. Liida ja minifitseeri CSS ja JavaScript

Tüüpilisel WordPressi saidil on 40+ JS-faili ja 20+ CSS-faili. Igaüks neist on eraldi HTTP-päring. See teeb kokku 60+ serverikutset ainult skriptide ja stiilide jaoks, mis kõik laadivad enne sisu ilmumist.

Minifitseerimine eemaldab failidest kõik ebavajaliku: tühikud, reavahetused, kommentaarid. Fail muutub kergemaks, kuid HTTP-päringute arv jääb samaks.

Liitmine ühendab mitu faili üheks. Viiest CSS-failist saab kaks (üks „above-the-fold" jaoks, teine kõige muu jaoks). Viiest JS-failist samamoodi. Ja kümne päringu asemel on sul kaks või kolm.

Kõige populaarsem tasuta tööriist selleks on Autoptimize. Plugin, millel on miljon aktiivset installatsiooni ja hinnang 4,7. Seadetes on kolm märkeruutu: optimeeri HTML, CSS ja JS. Märgi kõik kolm ja näed koheseid tulemusi.

Peenemaks juhtimiseks on olemas WP Rocket, tasuline lahendus, mis ühendab failid, minifitseerib need ja lisab vahemälu ühes liideses.

Pärast kombineerimist kontrolli saiti alati inkognito režiimis: mõnikord lõhub failide liitmine kujunduse. Kui midagi tundub valesti, keela probleemse faili kombineerimine ja jäta alles ainult tihendamine.

🔗 WP Rocketi ametlik veebisait

Üks asi veel: failide kombineerimine ei ole imerohi. Kui mõni plugin laeb väliseid skripte CDN-ist (Google Fonts, reCAPTCHA, YouTube'i mängija), ei saa sa neid kombineerida. Saad neid ainult edasi lükata või asünkroonselt laadida, mis toobki meid järgmise sammu juurde.

4. Samm: tegele renderdamist blokeerivate skriptidega

Brauser loeb lehte ülevalt alla. Kui see kohtab <head> jaotises <script src="...">, peatab see renderdamise, laeb skripti täielikult alla ja alles seejärel jätkab. Külastajad näevad selle aja jooksul tühja lehte.

Lahendus on viia skriptid, mida pole esimese ekraani kuvamiseks vaja, lehe lõppu või lisada atribuut async/defer. Erinevus:

• defer: skript laaditakse taustal, kuid käivitatakse rangelt pärast HTML-i parsimise lõppu ja nende kaasamise järjekorras;
• async: skript laaditakse ja käivitatakse esimesel võimalusel, ilma garanteeritud järjekorrata.

WordPressi jaoks on olemas tasuta plugin nimega Async JavaScript. See lisab selge liidese kaudu valitud skriptidele async või defer. See töötab kohe algusest peale, kuid nõuab ettevaatust: kui async-iga lisatud skript peab käivituma enne teist, võib leht katki minna.

Ohutu lähenemine on testida ühe skriptiga, kontrollida saiti inkognito režiimis ja seejärel liikuda järgmise juurde.

WP Rocket oskab samuti skripte edasi lükata: minge File Optimization → Load JavaScript deferred. Valige „Deferred" ja lisage jQuery erandite hulka, kuna enamik WordPressi teemasid ja pluginaid sõltub sellest.

Tulemus: leht hakkab varem renderduma, isegi kui HTTP-päringute koguarv pole muutunud. Külastajad näevad sisu, samal ajal kui ülejäänud skriptid taustal laadivad.

5. Samm: lubage vahemälu ja CDN

Vahemälu vähendab korduvkülastuste HTTP-päringuid otseselt. Mehhanism on lihtne: brauser salvestab staatilised failid (CSS, JS, pildid, fondid) lokaalselt. Järgmisel lehe laadimisel tõmbab brauser faili serverilt küsimise asemel vahemälust. Selle faili jaoks null HTTP-päringut.

Serveripoolne vahemälu on järgmine tase: server edastab juba kokku pandud HTML-lehe, selle asemel et käivitada kümneid PHP-päringuid andmebaasi. Vahemälu pluginad (WP Rocket, Flying Press, W3 Total Cache) teevad seda automaatselt.

CDN (Content Delivery Network) on ülemaailmne serverite võrk. Selle asemel, et tõmmata faile teie majutusest Hollandis Brasiilia külastaja jaoks, edastab CDN need lähimast sõlmest. Lisaks sisaldavad CDN-teenuse pakkujad sageli koheselt tihendamist, minifitseerimist ja pildi optimeerimist.

Cloudflare on tasuta võimalus, mis katab põhivajadused: CDN, DDoS-kaitse, tasuta SSL.

Paigaldage WordPressile Cloudflare'i plugin. See ühendab teie saidi CDN-iga ja pakub põhiseadeid otse administraatori paneelist. Täpsemaks juhtimiseks minge Cloudflare'i armatuurlauale: lubage CSS/JS/HTML-i Auto Minify, Brotli tihendamine ja Rocket Loader asünkroonseks skriptide laadimiseks.

🔗 Cloudflare WordPress.org-is

Vahemälu ja CDN-iga langeb korduvkülastajate HTTP-päringute arv drastiliselt. Esimene külastus: täielik laadimine. Teine külastus: enamik faile tuleb brauseri vahemälust ja lähimast CDN-sõlmest, ilma ühegi pöördumiseta teie serveri poole.

Boonus: kontrollige, kas teie server toetab HTTP/2

HTTP/2 on protokoll, mis edastab mitu faili ühe TCP-ühenduse kaudu. Brauser ei oota faili nr 1 allalaadimise lõppu, enne kui küsib faili nr 2; need laaditakse paralleelselt. See vähendab suure HTTP-päringute arvu mõju: 60 faili üle HTTP/2 laadivad kiiremini kui needsamad 60 üle HTTP/1.1.

Kontrollige oma serverit KeyCDN HTTP/2 Test tööriistaga. Sisestage oma domeen ja klõpsake „Test". Tulemus „HTTP/2 is supported" tähendab, et multipleksimine töötab.

Kui test näitab HTTP/1.1, võtke ühendust oma majutusteenuse pakkujaga. Enamik kaasaegseid majutusteenuse pakkujaid (SiteGround, Cloudways, Kinsta) lubab HTTP/2 vaikimisi. 2010. aastate jagatud majutusel ei pruugi see nii olla. Kontrollige ka oma PHP versiooni: kaasaegsele PHP versioonile üleminek annab märgatava jõudluse tõuke, samas kui aegunud versioonid töötlevad päringuid oluliselt aeglasemalt. Kui teie majutusteenuse pakkuja ei uuenda ei protokolli ega PHP versiooni, võib olla aeg kaaluda teenusepakkuja vahetamist.

Kui eelistate videoformaati, siis siin on visuaalne juhend HTTP-päringute vähendamiseks WordPressis (12 minutit).

⁉️🤔 Korduma kippuvad küsimused

Kui palju HTTP-päringuid peetakse WordPressi puhul normaalseks?

Sihtvahemik on 30 kuni 60 lehe kohta. Kõik üle 80-90 nõuab optimeerimist. GTMetrix ja Pingdom näitavad oma aruannetes konkreetseid numbreid. Pärast selle artikli viie sammu rakendamist on realistlik langeda 130-lt 35-45 päringuni.

„Mul on sait Elementoril ja sellel on juba 100+ päringut. Kas see on normaalne?"

Leheehitajad genereerivad oma olemuselt palju CSS-i ja JS-i. Elementor ja Divi lisavad ise 30-50 päringut. See ei tähenda „leppige sellega"; see tähendab, et ülejäänud teie sait peaks olema võimalikult puhas. Eemaldage kõik, mis ei ole ehituskomplektiga seotud: mittevajalikud pluginad, välised fondid, optimeerimata pildid. Hoidke alles ainult see, mis teie külastajaid tegelikult teenindab.

Kumb on olulisem: päringute arv või lehe kogumaht?

Mõlemad. 20 päringut, igaüks 1 MB, tähendab 20-sekundilist lehe laadimist. 100 päringut, igaüks 5 KB, võivad laadida kiiremini, kuid iga päring toob kaasa üldkulu DNS-i päringu, TCP-ühenduse ja TLS-kätluse jaoks. HTTP/2 puhul see erinevus tasandub. HTTP/1.1 puhul on see kriitiline. Optimeerige mõlemat: vähendage päringute arvu failide kombineerimise ja spraitide abil, vähendage mahtu tihendamise ja minifitseerimise kaudu.

Kas ma saan hakkama ilma pluginateta?

Osaliselt jah. CSS/JS-i minifitseerimist saab seadistada teema arendamise ajal Gulp'i või Webpacki kaudu. HTTP/2 lubatakse serveri tasemel (Nginx/Apache konfiguratsioon). Vahemälu saab teha serverireeglite kaudu. Kuid enamiku WordPressi saidiomanike jaoks on pluginad kõige praktilisem tee: seadistamine võtab minuteid, tulemused on kohesed ja saidi katki tegemise risk on väiksem.

Kui sageli peaksin HTTP-päringute arvu uuesti kontrollima?

Pärast iga suuremat plugina paigaldamist või uuendamist. Uus plugin võib lisada oma CSS/JS-i kõigile lehtedele ja te ei märka seda enne, kui sait hakkab hanguma. Rutiinseks kontrolliks piisab kord kuus. GTMetrix võimaldab seadistada automaatse jälgimise koos hoiatustega, kui jõudlus langeb.

Kas ma üldse vajan seda juhendit, kui mul on juba kiire majutus?

Majutus lahendab osa probleemist serveri tasemel, kuid mitte koodi tasemel. Kui mõni plugin lisab lehe <head> sektsiooni 15 skripti, ei pane isegi tipptasemel serverid neid hetkega laadima. Brauser jääb ikkagi ootama. Kiire majutus annab edumaa, kuid tegelik võitja on see, kes koristab ära ka kliendipoolse osa.

Mis tegelikult vähendab HTTP-päringuid ja mis mitte?

Vaatame kõik sammud läbi ilma illusioonideta:

• Pluginatest ja teemadest koristamine annab kõige märgatavama paranemise. Iga eemaldatud plugin kaotab oma CSS-i, JS-i ja välised päringud. Praktikas kaob pärast auditit 10-30 päringut.
• Piltide tihendamine vähendab failimahte, kuid päringute arv jääb samaks. Küll aga langeb lehe kogulaadimisaeg märgatavalt.
• CSS-i ja JS-i ühendamine vähendab päringute arvu oluliselt. Miinus: see võib kujunduse lõhkuda, seega kontrolli pärast iga muudatust.
• Skriptide edasilükatud laadimine: päringute arv sama, kuid leht muutub nähtavaks varem.
• Vahemälu ja CDN: uute külastajate jaoks on erinevus minimaalne. Korduvkülastajatel toimub lehe taaslaadimine ilma ühegi päringuta serverisse.

Kui peaksime valima täpselt kolm tegevust, mis tüüpilisele WordPressi saidile suurimat mõju avaldavad: (1) eemalda mittevajalikud pluginad, (2) luba CSS/JS ühendamine Autoptimize'i abil, (3) seadista Cloudflare. Need on kolm sammu, mis võtavad aega ühe õhtu, mitte nädala, ja tulemusi näed GTMetrixi numbrites juba järgmisel päeval.