Sivustosi on hidas, ja GTMetrix näyttää yli 130 HTTP-pyyntöä sivua kohden?

Tämä ei ole mikään abstrakti luku raportista. Jokainen pyyntö on selaimen kutsu palvelimelle tiedostoa varten: skripti, tyylitiedosto, kuva tai fontti. Mitä enemmän pyyntöjä on, sitä kauemmin kävijät tuijottavat tyhjää ruutua. Portentin mukaan latausviive nollasta kolmeen sekuntiin vähentää konversiota 2,5%. Ja jokainen ylimääräinen sekunti sen jälkeen maksaa vielä 4,4%.

HTTP-pyyntöjen ongelma ei ole niiden olemassaolo. Ongelma on se, että useimmat WordPress-sivustot tuottavat niitä paljon enemmän kuin on tarpeen. Alla on viisi konkreettista toimenpidettä, jotka vähentävät pyyntöjen määrää ilman, että koko sivusto tarvitsee kirjoittaa uusiksi.

💡 Nopea yleiskatsaus:

• Poista tarpeettomat lisäosat ja teemat, jotka luovat ylimääräisiä pyyntöjä jokaisella sivulla
• Optimoi kuvat: pakkaa tiedostot, poista turhat kuvat, yhdistä kuvakkeet spriteiksi
• Yhdistä CSS ja JavaScript 1-2 tiedostoon ja ota minifiointi käyttöön
• Määritä laiskalataus skripteille, jotka estävät sivun renderöinnin
• Ota käyttöön välimuisti ja CDN, jotta palaavat kävijät eivät lataa koko sivustoa uudelleen

Vaihe 1. Karsi turha pois

Jokainen asennettu lisäosa tuo mukanaan tiedostoja. PHP, CSS, JavaScript: mikä tahansa näistä luo HTTP-pyynnön sivun latautuessa. Kaksikymmentä lisäosaa tarkoittaa lähes sataa pyyntöä jo pelkästään käynnistyksessä, ennen mitään sisältöä.

Ensimmäinen tehtävä on auditointi. Avaa Lisäosat → Asennetut lisäosat ja kysy itseltäsi rehellisesti: mitkä ovat kriittisiä sivuston toiminnalle ja mitkä vain lojuvat siellä "kaiken varalta"? Se SEO-analysaattori, jonka asensit vuosi sitten ja avasit kahdesti, on poistoehdokas. Samoin sosiaalisten kuvakkeiden lisäosa, jos olet jo lisännyt linkit alatunnisteeseen muutenkin.

Oma kategoriansa ovat lisäosat, jotka yhdistävät kolmannen osapuolen palvelimiin. Live-chat, nettiraadio, push-ilmoitukset. Jokainen tällainen lisäosa luo ylimääräisiä ulkoisia HTTP-pyyntöjä kolmannen osapuolen palvelimille. Poista kaikki, mitä ilman sivusto toimii. Tarvitsetko sitä kerran kuussa? Asenna se päiväksi ja poista sitten.

Sama sääntö koskee teemoja. Kohdassa Ulkoasu → Teemat, pidä vain aktiivinen teemasi ja yksi varateema (esimerkiksi oletusteema Twenty Twenty-Five). Poista loput.

Jos lisäosaa tarvitaan, mutta vain tietyllä sivulla, lataa se valikoivasti. Asset CleanUp: Page Speed Booster tekee juuri tämän. Se on ilmainen lisäosa, jolla on yli 100 000 aktiivista asennusta ja arvosana 4,7 WordPress.orgissa.

Lisäosa skannaa sivun, näyttää listan ladatuista CSS- ja JS-tiedostoista ja antaa sinun poistaa käytöstä tietyt tiedostot tietyillä sivuilla, sisältötyypeillä tai koko sivuston laajuisesti. Tarvitsetko Contact Form 7:ää vain yhteydenottosivulla? Poista sen valinta kaikkialta muualta, niin sen skriptit eivät lataudu siellä, missä lomaketta ei käytetä.

🔗 Asset CleanUp WordPress.orgissa

Samalla kannattaa optimoida tietokanta. Lisäosien siivouksen jälkeen niiden asetukset ja tietueet jäävät tauluihin, ja ne pitäisi myös poistaa. Tarkista myös rikkinäiset linkit: jokainen uudelleenohjaus on ylimääräinen HTTP-pyyntö.

Nähdäksesi ongelman laajuuden selvästi ennen ja jälkeen, testaa sivustosi GTMetrixissä:

Ensimmäinen ajo näyttää lähtötason: pyyntöjen määrän, sivun kokonaiskoon, latausajan. Jokaisen tämän artikkelin vaiheen jälkeen, aja testi uudelleen. Näin näet, millä muutoksilla oli suurin vaikutus.

Vaihe 2. Optimoi kuvat

Kuvat ovat keskimääräisen WordPress-sivun suurin "paino". HTTP Archiven mukaan kuvien osuus on noin 44% sivun kokonaiskoosta työpöydällä. Ja jokainen kuva on HTTP-pyyntö.

Aloita poistamalla käyttämättömät tiedostot. Kohdassa Media → Kirjasto, suodata "Liittämätön". Nämä ovat kuvia, joita ei ole liitetty mihinkään artikkeliin. Jos niitä ei käytetä teemassa tai alatunnisteessa, poista ne.

Seuraavaksi tulee pakkaus. Lisäosat, kuten WP Compress, hoitavat tämän automaattisesti: kun lataat kuvan, se kulkee pilvioptimoijan läpi, pakkautuu ilman näkyvää laadun heikkenemistä ja muunnetaan WebP- tai AVIF-muotoon. Nämä formaatit ovat huomattavasti kevyempiä kuin JPEG samalla visuaalisella laadulla. Googlen mukaan WebP pienentää tiedostokokoa keskimäärin 25-35% verrattuna JPEGiin.

WP Compressilla on yli 10 000 aktiivista asennusta, arvosana 4,5/5 ja yli 1,1 miljoonaa latausta WordPress.orgissa. Ensimmäiset 100 kuvaa ovat ilmaisia, mikä riittää eron huomaamiseen.

🔗 WP Compress WordPress.orgissa

Pelkkä pakkaus ei vähennä HTTP-pyyntöjen määrää. Mutta se pienentää jokaisen tiedoston kokoa, mikä tarkoittaa lyhyempää siirtoaikaa. Yhdistettynä muihin toimenpiteisiin tämä tuo huomattavan nopeusedun.

CSS-spritet: yksi tiedosto kymmenen sijaan

Jos sivullasi on tusina pientä kuvaketta (sosiaaliset verkostot, nuolet, arvostelutähdet), jokainen latautuu erillisenä pyyntönä. CSS-sprite ratkaisee tämän: kaikki kuvakkeet yhdistetään yhdeksi tiedostoksi, ja CSS näyttää tarvittavan palasen.

Näin se toimii: viisi kuvaa tarkoittaa viittä palvelinpyyntöä. Nuo samat viisi kuvaa yhdistettynä yhdeksi spriteksi tarkoittavat yhtä pyyntöä. Verkkotyökalut, kuten CSS Sprite Generator, voivat luoda spritejä puolestasi. Perus CSS-osaamista tarvitaan background-position-asetuksen määrittämiseen kullekin kuvakkeelle.

Huomio: jos palvelimesi tukee HTTP/2:ta, tiedostot latautuvat asynkronisesti yhden yhteyden sisällä. Siinä tapauksessa spriten tuomat säästöt ovat vähemmän havaittavia. Mutta käytännössä tusina kuvaketta yhdessä tiedostossa latautuu silti nopeammin kuin kymmenen erillistä.

Vaihe 3. Yhdistä ja minifioi CSS ja JavaScript

Tyypillisellä WordPress-sivustolla on yli 40 JS-tiedostoa ja yli 20 CSS-tiedostoa. Jokainen niistä on erillinen HTTP-pyyntö. Se tekee yli 60 palvelinkutsua pelkästään skripteille ja tyyleille, jotka kaikki latautuvat ennen kuin mitään sisältöä ilmestyy näkyviin.

Minifiointi poistaa tiedostoista kaiken tarpeettoman: välilyönnit, rivinvaihdot, kommentit. Tiedostosta tulee kevyempi, mutta HTTP-pyyntöjen määrä pysyy samana.

Yhdistäminen sulauttaa useita tiedostoja yhdeksi. Viidestä CSS-tiedostosta tulee kaksi (yksi alkunäkymälle, yksi kaikelle muulle). Viidestä JS-tiedostosta sama juttu. Ja kymmenen pyynnön sijaan jäljellä on kaksi tai kolme.

Suosituin ilmainen työkalu tähän on Autoptimize. Lisäosa, jolla on miljoona aktiivista asennusta ja arvosana 4,7. Asetuksissa on kolme valintaruutua: optimoi HTML, CSS ja JS. Valitse kaikki kolme ja näet välittömät tulokset.

Tarkempaa hallintaa varten on olemassa WP Rocket, premium-ratkaisu, joka yhdistää tiedostot, minifioi ne ja lisää välimuistin yhdellä käyttöliittymällä.

Yhdistämisen jälkeen tarkista sivustosi aina incognito-tilassa: joskus tiedostojen yhdistäminen rikkoo asettelun. Jos jokin näyttää väärältä, poista yhdistäminen käytöstä ongelmallisen tiedoston osalta ja pidä vain minifiointi.

🔗 WP Rocketin virallinen sivusto

Vielä yksi huomio: tiedostojen yhdistäminen ei ole taikaratkaisu. Jos jokin lisäosa lataa ulkoisia skriptejä CDN:stä (Google Fonts, reCAPTCHA, YouTube-soitin), et voi yhdistää niitä. Voit ainoastaan lykätä niiden latausta tai ladata ne asynkronisesti, mikä tuo meidät seuraavaan vaiheeseen.

Vaihe 4. Käsittele renderöinnin estävät skriptit

Selain lukee sivua ylhäältä alas. Kun se kohtaa <script src="...">-elementin <head>-osiossa, se pysäyttää renderöinnin, lataa skriptin kokonaan ja jatkaa vasta sitten. Vierailijat näkevät tänä aikana tyhjän sivun.

Ratkaisu on siirtää skriptit, joita ei tarvita ensimmäisen ruudun renderöintiin, sivun alaosaan tai lisätä async/defer-attribuutti. Ero:

• defer: skripti latautuu taustalla, mutta suoritetaan vasta, kun HTML:n jäsennys on valmis, ja siinä järjestyksessä kuin ne on lisätty;
• async: skripti latautuu ja suoritetaan heti tilaisuuden tullen, eikä järjestys ole taattu.

WordPressille on ilmainen lisäosa nimeltä Async JavaScript. Se lisää async- tai defer-attribuutin valittuihin skripteihin selkeän käyttöliittymän kautta. Se toimii suoraan laatikosta otettuna, mutta vaatii varovaisuutta: jos async-attribuutilla lisätty skripti pitää suorittaa ennen toista, sivu voi hajota.

Turvallinen lähestymistapa on testata yhdellä skriptillä, tarkistaa sivusto incognito-tilassa ja siirtyä sitten seuraavaan.

WP Rocket voi myös lykätä skriptejä: mene kohtaan File Optimization → Load JavaScript deferred. Valitse "Deferred" ja lisää jQuery poikkeuksiin, sillä useimmat WordPress-teemat ja lisäosat ovat siitä riippuvaisia.

Tulos: sivu alkaa renderöityä aiemmin, vaikka HTTP-pyyntöjen kokonaismäärä ei olisi muuttunut. Vierailijat näkevät sisältöä, kun loput skriptit latautuvat taustalla.

Vaihe 5. Ota käyttöön välimuisti ja CDN

Välimuisti vähentää HTTP-pyyntöjä suoraan toistuvilla vierailuilla. Mekaniikka on yksinkertainen: selain tallentaa staattiset tiedostot (CSS, JS, kuvat, fontit) paikallisesti. Seuraavalla sivulatauksella se hakee tiedoston välimuistista sen sijaan, että pyytäisi sitä palvelimelta. Nolla HTTP-pyyntöä kyseiselle tiedostolle.

Palvelinpuolen välimuisti on seuraava taso: palvelin toimittaa valmiiksi kootun HTML-sivun sen sijaan, että se suorittaisi kymmeniä PHP-kyselyjä tietokantaan. Välimuistilisäosat (WP Rocket, Flying Press, W3 Total Cache) tekevät tämän automaattisesti.

CDN (Content Delivery Network) on maailmanlaajuinen palvelinverkko. Sen sijaan, että tiedostot haettaisiin hollantilaiselta palvelimeltasi brasilialaiselle vierailijalle, CDN toimittaa ne lähimmältä solmupisteeltä. Lisäksi CDN-palveluntarjoajat sisällyttävät usein pakkauksen, minifioinnin ja kuvien optimoinnin suoraan pakettiin.

Cloudflare on ilmainen vaihtoehto, joka kattaa perustarpeet: CDN, DDoS-suojaus, ilmainen SSL.

Asenna Cloudflare-lisäosa WordPressille. Se yhdistää sivustosi CDN:ään ja tarjoaa perusasetukset suoraan hallintapaneelista. Tarkempaa hallintaa varten mene Cloudflaren hallintapaneeliin: ota käyttöön Auto Minify CSS/JS/HTML:lle, Brotli-pakkaus ja Rocket Loader asynkronista skriptien latausta varten.

🔗 Cloudflare WordPress.orgissa

Välimuistin ja CDN:n avulla HTTP-pyyntöjen määrä putoaa dramaattisesti palaaville vierailijoille. Ensimmäinen vierailu: täysi lataus. Toinen vierailu: useimmat tiedostot tulevat selaimen välimuistista ja lähimmältä CDN-solmupisteeltä ilman kutsuja palvelimellesi.

Bonus: tarkista, tukeeko palvelimesi HTTP/2:ta

HTTP/2 on protokolla, joka siirtää useita tiedostoja yhden TCP-yhteyden kautta. Selain ei odota, että tiedosto #1 on ladattu loppuun, ennen kuin se pyytää tiedostoa #2; ne latautuvat rinnakkain. Tämä vähentää suuren HTTP-pyyntömäärän vaikutusta: 60 tiedostoa HTTP/2:n yli latautuu nopeammin kuin samat 60 HTTP/1.1:n yli.

Tarkista palvelimesi käyttämällä KeyCDN:n HTTP/2-testityökalua. Syötä verkkotunnuksesi ja napsauta "Test." Tulos "HTTP/2 is supported" tarkoittaa, että multiplexaus toimii.

Jos testi näyttää HTTP/1.1:n, ota yhteyttä palveluntarjoajaasi. Useimmat nykyaikaiset hosting-palveluntarjoajat (SiteGround, Cloudways, Kinsta) ottavat HTTP/2:n oletuksena käyttöön. 2010-luvun jaetuissa hosting-palveluissa näin ei välttämättä ole. Tarkista myös PHP-versiosi: päivittäminen nykyaikaiseen PHP-versioon antaa huomattavan suorituskyvyn lisäyksen, kun taas vanhentuneet versiot käsittelevät pyynnöt merkittävästi hitaammin. Jos palveluntarjoajasi ei päivitä protokollaa eikä PHP-versiota, saattaa olla aika harkita palveluntarjoajan vaihtamista.

Jos pidät enemmän videomuodosta, tässä on visuaalinen opas HTTP-pyyntöjen vähentämiseen WordPressissä (12 minuuttia).

⁉️🤔 Usein kysytyt kysymykset

Kuinka monta HTTP-pyyntöä pidetään normaalina WordPressille?

Tavoitealue on 30-60 per sivu. Kaikki yli 80-90 vaatii optimointia. GTMetrix ja Pingdom näyttävät tarkat luvut raporteissaan. Tämän artikkelin viiden vaiheen soveltamisen jälkeen on realistista pudota 130 pyynnöstä 35-45 pyyntöön.

"Minulla on sivusto Elementorilla, ja siinä on jo yli 100 pyyntöä. Onko se normaalia?"

Sivunrakentajat tuottavat luonnostaan paljon CSS:ää ja JS:ää. Elementor ja Divi lisäävät yksinään 30-50 pyyntöä. Tämä ei tarkoita "hyväksy se"; se tarkoittaa, että muun sivustosi tulisi olla mahdollisimman puhdas. Poista kaikki, mikä ei liity sivunrakentajaan: tarpeettomat lisäosat, ulkoiset fontit, optimoimattomat kuvat. Pidä vain se, mikä todella palvelee vierailijoitasi.

Kumpi on tärkeämpää: pyyntöjen määrä vai sivun kokonaiskoko?

Molemmat. 20 pyyntöä, kukin 1 Mt, tarkoittaa 20 sekunnin sivulatausta. 100 pyyntöä, kukin 5 kt, saattaa latautua nopeammin, mutta jokaisesta pyynnöstä koituu yleiskustannuksia DNS-haulle, TCP-yhteydelle ja TLS-kättelylle. HTTP/2:lla tämä ero tasoittuu. HTTP/1.1:llä se on kriittinen. Optimoi molemmat: vähennä pyyntöjen määrää tiedostoja yhdistelemällä ja spriteillä, pienennä kokoa pakkauksella ja minifioinnilla.

Pärjäänkö ilman lisäosia?

Osittain kyllä. CSS/JS-minifioinnin voi määrittää Gulpilla tai Webpackilla teemakehityksen aikana. HTTP/2 otetaan käyttöön palvelintasolla (Nginx/Apache-konfiguraatio). Välimuistin voi toteuttaa palvelinsäännöillä. Mutta useimmille WordPress-sivuston omistajille lisäosat ovat käytännöllisin tapa: käyttöönotto vie minuutteja, tulokset ovat välittömiä ja riski sivuston hajoamisesta on pienempi.

Kuinka usein HTTP-pyyntöjen määrä pitäisi tarkistaa uudelleen?

Jokaisen suuremman lisäosan asennuksen tai päivityksen jälkeen. Uusi lisäosa saattaa lisätä CSS/JS-tiedostonsa kaikille sivuille, etkä huomaa sitä ennen kuin sivusto alkaa hidastella. Kerran kuukaudessa riittää rutiinitarkistuksiin. GTMetrixissä voit määrittää automaattisen seurannan ja hälytykset, kun suorituskyky laskee.

Tarvitsenko tätä opasta, jos minulla on jo nopea hosting?

Hosting ratkaisee osan ongelmasta palvelintasolla, mutta ei kooditasolla. Jos lisäosa lisää 15 skriptiä sivun <head>-osioon, edes huippuluokan palvelimet eivät saa niitä latautumaan välittömästi. Selain odottaa yhä. Nopea hosting antaa etumatkan, mutta todellinen voittaja on se, joka siivoaa myös asiakaspuolen.

Mikä oikeasti vähentää HTTP-pyyntöjä ja mikä ei?

Käydään läpi kaikki vaiheet ilman harhakuvitelmia:

• Lisäosien ja teemojen siivoaminen tuo huomattavimman parannuksen. Jokainen poistettu lisäosa poistaa sen CSS:n, JS:n ja ulkoiset kutsut. Käytännössä auditoinnin jälkeen katoaa 10-30 pyyntöä.
• Kuvien pakkaus pienentää tiedostokokoja, mutta pyyntöjen määrä pysyy samana. Kokonaislatausaika kuitenkin lyhenee selvästi.
• CSS:n ja JS:n yhdistäminen vähentää pyyntöjen määrää merkittävästi. Haittapuoli: se voi rikkoa asettelun, joten tarkista jokaisen muutoksen jälkeen.
• Skriptien lykätty lataus: pyyntöjen määrä sama, mutta sivu tulee näkyviin nopeammin.
• Välimuisti ja CDN: uusille kävijöille ero on minimaalinen. Palaaville kävijöille sivun toistuvat lataukset tapahtuvat ilman yhtäkään pyyntöä palvelimelle.

Jos pitäisi valita tasan kolme toimenpidettä, joilla on suurin vaikutus tyypillisellä WordPress-sivustolla: (1) poista tarpeettomat lisäosat, (2) ota CSS/JS-yhdistäminen käyttöön Autoptimizella, (3) määritä Cloudflare. Nämä ovat kolme askelta, jotka vievät illan eivätkä viikkoa, ja näet tulokset GTMetrixin luvuissa jo seuraavana päivänä.