Selainvälimuistin kestoajat määritellään HTTP-välimuistisäännöillä, jotka kertovat, kuinka kauan sivustosi staattisia tiedostoja säilytetään kävijän selaimessa. Käytännössä CSS-, JavaScript-, kuva-, fontti- ja ikonitiedostoille asetetaan Välimuistin hallinta- ja joissain ympäristöissä Expires-otsakkeet. Esimerkiksi versioiduille CSS- ja JS-tiedostoille annetaan 1 vuosi, kuville 30 päivää–1 vuosi ja HTML-sivuille lyhyt aika tai uudelleenvahvistus. Oikea asetus estää samojen tiedostojen turhan uudelleenlataamisen, nopeuttaa sivun avautumista ja parantaa Core Web Vitals -mittareita.
Tässä oppaassa käymme läpi, miten selainvälimuisti toimii, kuinka monta sekuntia millekin tiedostolle kannattaa antaa ja miten asetukset toteutetaan Apache-, Nginx-, LiteSpeed-, WordPress- ja CDN-ympäristöissä. Tavoitteena ei ole pelkkä vihreä tulos nopeustestissä, vaan ajantasaisten tiedostojen tarjoaminen käyttäjälle samalla, kun palvelimen resursseja hyödynnetään tehokkaasti, TTFB ja kaistankulutus pienenevät ja uudelleenkäynneillä saavutetaan tuntuva nopeushyöty. Erityisesti jaetussa hostingissa, WordPress-hostingissa ja yritysprojekteissa oikea välimuististrategia on yksi kustannustehokkaimmista suorituskyvyn parannuksista. Hostragons verkkohostingpaketit
Mitä selainvälimuisti on?
Selainvälimuisti tarkoittaa verkkosivun avaamisen yhteydessä ladattujen staattisten resurssien tilapäistä tallentamista käyttäjän laitteelle. Kun kävijä saapuu etusivullesi, logo, CSS-tiedosto, JavaScript-tiedostot, fontit ja kuvat ladataan. Jos näille tiedostoille on asetettu oikeat välimuistiotsakkeet, selain ei pyydä osaa näistä tiedostoista palvelimelta uudelleen kävijän siirtyessä toiselle sivulle tai palatessa sivustolle myöhemmin. Näin sivu latautuu nopeammin.
Kuvitellaan esimerkiksi 2 Mt:n kokoinen etusivu. Siitä 1,4 Mt on kuvia, 300 kt CSS- ja JS-tiedostoja ja 100 kt fontteja. Ensimmäisellä käynnillä nämä resurssit ladataan. Toisella käynnillä selain kuitenkin käyttää näitä staattisia resursseja paikallisesti, jolloin verkon yli siirrettävän datan määrä vähenee dramaattisesti. Tämä ero korostuu mobiiliyhteyksillä ja paljon liikennettä saavilla sivustoilla.
Selainvälimuistia ei pidä sekoittaa palvelinpuolen välimuistiin. Palvelinvälimuisti tallentaa PHP-tulosteen tai tietokantakyselyt palvelimelle. Selainvälimuisti taas mahdollistaa kävijän laitteella olevien resurssien uudelleenkäytön. Parhaan suorituskyvyn saavuttamiseksi molemmat kerrokset on suunniteltava yhdessä. WordPress-sivustoilla sivuvälimuisti, objektivälimuisti, CDN-välimuisti ja selainvälimuisti ovat yleensä osa samaa optimointistrategiaa. WordPress-hosting ja suorituskyvyn optimointi
Miksi selainvälimuisti on tärkeä hakukoneoptimoinnille?
Google arvostaa sivustoja, jotka tarjoavat nopean ja vakaan käyttökokemuksen. Selainvälimuisti ei yksin takaa parempia sijoituksia, mutta se tukee hakukoneoptimointia vaikuttamalla sivun nopeuteen, vuorovaikutuksen viiveeseen ja resurssien lataustehokkuuteen. Se vaikuttaa merkittävästi erityisesti uudelleenkäynneissä, kategoriaselauksessa, tuotesivujen välillä siirtymisessä ja blogin sisäisessä navigoinnissa.
Vuoden 2026 SEO-standardeissa tekninen suorituskyky ei tarkoita pelkkää Lighthouse-pistettä. Googlen arvioima käyttäjäkokemus liittyy LCP-, INP-, CLS- ja TTFB-mittareihin sekä todelliseen käyttäjädataan. CSS- ja JS-tiedostojen turha uudelleenlataaminen voi pidentää LCP-aikaa. Fonttien pyytäminen uudelleen jokaisella sivulla voi vaikuttaa visuaaliseen vakauteen. Suurten kuvien välimuistittamattomuus voi aiheuttaa hitauden tunteen mobiilikäyttäjälle.
- Nopeammat uudelleenkäynnit: Käyttäjä ei lataa samoja tiedostoja uudestaan.
- Pienempi kaistankulutus: Palvelinliikenne vähenee ja hosting-resursseja käytetään tehokkaammin.
- Parempi indeksoinnin tehokkuus: Staattisten resurssien tarjoilu on sujuvampaa sekä roboteille että käyttäjille.
- Pienempi välittömän poistumisen riski: Nopeasti avautuvat sivut lisäävät käyttäjän sitoutumista.
- Johdonmukaisempi suorituskyky: CDN- ja hosting-puolen kuormituspiikit tasapainottuvat paremmin.
Keskeiset HTTP-välimuistiotsakkeet
Selainvälimuistin kestoja hallitaan HTTP-vastausotsakkeilla. Yleisimmät otsakkeet ovat Cache-Control, Expires, ETag ja Last-Modified. Nykyaikaisissa projekteissa pääasiallinen ohjauspiste on Cache-Control-otsake; Expires-otsaketta käytetään lähinnä taaksepäin yhteensopivuuden varmistamiseksi.
Välimuistin hallinta
Cache-Control kertoo selaimelle ja välissä oleville välimuistijärjestelmille, miten tiedosto tulee tallentaa. Yleisimmin käytetyt direktiivit ovat:
- max-age: Määrittää, kuinka monta sekuntia resurssia pidetään tuoreena. Esimerkiksi max-age=31536000 on noin 1 vuosi.
- public: Ilmaisee, että resurssi voidaan tallentaa jaettuihin välimuisteihin, kuten selaimeen ja CDN:ään.
- private: Ilmaisee, että resurssi tulee tallentaa vain käyttäjän omaan selaimeen.
- no-cache: Edellyttää, että resurssi on vahvistettava palvelimella ennen käyttöä; tämä ei tarkoita välimuistin täydellistä poiskytkemistä.
- no-store: Kieltää resurssin tallentamisen mihinkään; sopii maksu-, hallintapaneeli- ja henkilötietosivuille.
- immutable: Kertoo, ettei resurssi muutu ennen sen voimassaoloajan päättymistä; ihanteellinen tiedostonimellä versioiduille resursseille.
Esimerkki staattisen tiedoston otsakkeesta voisi olla: Cache-Control: public, max-age=31536000, immutable. Tämä kertoo selaimelle, että tiedostoa voi säilyttää vuoden, eikä sitä tarvitse tarkistaa uudelleen, ellei tiedostonimi muutu.
Expires
Expires-otsake määrittää päivämäärän ja kellonajan, johon asti resurssi on voimassa. Esimerkiksi kuvalle voidaan asettaa 30 päivän päähän osoittava Expires-arvo. Koska Expires käyttää absoluuttista päivämäärää, se ei ole yhtä joustava kuin Cache-Control. Nykyaikaisissa määrityksissä Cache-Control on ensisijainen; Expires voidaan lisätä vanhoja selaimia varten.
ETag ja Last-Modified
ETag ja Last-Modified ovat validointimekanismeja. Selain voi kysyä palvelimelta, onko sen hallussa oleva tiedostoversio edelleen ajantasainen. Jos tiedosto ei ole muuttunut, palvelin palauttaa 304 Not Modified -vastauksen, eikä tiedoston runkoa ladata uudelleen. Tämä menetelmä on hyödyllinen erityisesti usein muuttuvalle sisällölle, kuten HTML:lle, tai tiedostoille, joille ei haluta antaa pitkää välimuistiaikaa.
Mikä välimuistin kestoaika millekin tiedostotyypille?
Yleisin virhe on antaa sama kestoaika kaikille tiedostotyypeille. HTML-, CSS-, JS-, kuva-, fontti- ja API-vastauksilla on kuitenkin erilainen päivityskäyttäytyminen. Pääsääntö on yksinkertainen: jos tiedostonimi voidaan vaihtaa, voidaan antaa pitkä välimuistiaika; jos sisältö muuttuu usein ilman tiedostonimen vaihtumista, tulee käyttää lyhyttä aikaa tai validointia.
| Resurssityyppi | Suositeltu kesto | Suositeltu otsake | Huomautus |
|---|---|---|---|
| HTML-sivut | 0-10 minuuttia tai validointi | no-cache, max-age=0 | Sisällön tuoreus on etusijalla, jos se muuttuu usein. |
| CSS ja JS | 30 päivää–1 vuosi | public, max-age=31536000, immutable | Tiedosto tulee versioida: esim. style.v3.css. |
| Kuvat | 30 päivää–1 vuosi | public, max-age=2592000 tai 31536000 | Logot ja ikonit pitkäksi aikaa; kampanjakuvat lyhyemmäksi. |
| Fonttitiedostot | 6 kuukautta–1 vuosi | public, max-age=31536000, immutable | WOFF2-tiedostot muuttuvat yleensä harvoin. |
| PDF ja media | 7 päivää–6 kuukautta | public, max-age=604800 tai 15552000 | Päivittyvissä luetteloissa kesto on valittava huolella. |
| Ylläpito- ja maksusivut | Ei välimuistia | no-store, private | Tietoturva ja henkilötiedot ovat etusijalla. |
Tämä taulukko on yleinen lähtökohta. Verkkokauppasivustolla varasto- ja hintatietoja sisältäviä HTML-sivuja ei pidä välimuistittaa aggressiivisesti. Sen sijaan tuotekuvat voidaan välimuistittaa vuodeksi, kunhan tiedostonimi vaihdetaan. Yrityssivustolla logo, fontit ja teematiedostot voidaan säilyttää pitkään, mutta kampanjabannereiden kohdalla 7–30 päivää voi olla turvallisempi, jos ne vaihtuvat usein.
Miten selainvälimuistin kestoajat suunnitellaan?
Onnistuneen välimuististrategian perustana on sivuston tiedostojen luokittelu. Teknisesti on määriteltävä säännöt tiedostopäätteiden mukaan; strategisesti taas on määritettävä kesto päivitystiheyden perusteella.
1. Erottele staattiset ja dynaamiset resurssit
CSS, JS, JPG, PNG, WebP, SVG, WOFF2 ovat staattisia resursseja. HTML, ostoskori, käyttäjäpaneeli, hakutulokset ja API-vastaukset katsotaan dynaamisiksi. Staattiset resurssit välimuistitetaan pitkäksi aikaa, kun taas dynaamista sisältöä on hallittava tarkemmin. Erityisesti käyttäjäkohtaisessa sisällössä ei pidä käyttää julkista välimuistia.
2. Käytä tiedostojen versiointia
Turvallinen tapa pitkään välimuistiaikaan on tiedostojen versiointi. Jos esimerkiksi asetat style.css-tiedostolle vuoden välimuistiajan ja muutat sen sisältöä, osa käyttäjistä saattaa nähdä vanhan ulkoasun. Sen sijaan käyttämällä nimeämistapaa, kuten style.2026.01.css, app.v12.js tai tiedoston tiivisteen sisältävä app.8f3a2.js, uusi tiedostonimi julkaistaan päivityksen yhteydessä ja selain lataa uuden resurssin.
WordPress-teemat ja nykyaikaiset build-työkalut voivat tehdä tämän automaattisesti. Jos kehität teemaa, version-parametrin käyttö wp_enqueue_style- ja wp_enqueue_script-funktioissa helpottaa versiohallintaa kyselymerkkijonon tai tiedostonimen avulla. Koska jotkin CDN-määritykset saattavat käsitellä kyselymerkkijonoja eri tavoin, tiivisteen lisääminen tiedostonimeen on varmempi menetelmä.
3. Älä toimi aggressiivisesti HTML:n kanssa
HTML-sivut sisältävät käyttäjälle näkyvän pääsisällön, joten niitä hallitaan yleensä lyhytaikaisella välimuistilla tai uudelleenvahvistuksella. Blogikirjoituksissa 5–10 minuutin välimuisti voi riittää; uutis-, kampanja- tai hintasivuilla tarvitaan lyhyempi aika. Jos käytät WordPressissä sivuvälimuistia, selaimen välimuistiotsake on suunniteltava yhdessä palvelinvälimuistin ja CDN:n tyhjennysmekanismin kanssa.
4. Poista välimuisti käytöstä tietoturvaa vaativilla sivuilla
Kirjautumissivulla, asiakaspaneelissa, maksuvaiheessa, tilausyhteenvedossa, laskuissa ja henkilötietoja sisältävillä sivuilla tulee käyttää otsakkeita, kuten Cache-Control: no-store, private. Selainvälimuisti on suorituskykyä varten, mutta sen ei pidä vaarantaa henkilötietojen tietoturvaa. Myös SSL:n käyttö on tässä kohtaa perusedellytys. Hostragons SSL-sertifika
Selainvälimuistin asetukset Apache .htaccess -tiedostolla
Apache-palvelimilla selainvälimuisti määritetään yleensä .htaccess-tiedostolla. Tämä on käytännöllisin tapa monille jaetun hostingin käyttäjille. Ensin mod_expires- ja mod_headers-moduulien on oltava aktiivisia. Useimmissa laadukkaissa hosting-ympäristöissä nämä moduulit ovat valmiina.
Voit käyttää seuraavaa logiikkaa: kuville ja fonteille pitkä aika, CSS:lle ja JS:lle pitkä aika, HTML:lle lyhyt validointi. .htaccess-tiedostoon lisättävissä säännöissä määritellään ExpiresByType- ja Header set Cache-Control -määritykset tiedostotyyppien mukaan. Esimerkiksi image/webp-, image/jpeg-, image/png- ja image/svg+xml-tiedostoille 1 vuosi; text/css- ja application/javascript-tiedostoille 1 vuosi; text/html-tiedostoille no-cache.
Varmuuskopioi .htaccess-tiedosto ennen muutosten tekemistä. Väärin kirjoitettu sääntö voi aiheuttaa 500 Internal Server Error -virheen. Avaa sivusto muutoksen jälkeen incognito-tilassa ja tarkista DevTools Network -välilehdeltä kyseisen tiedoston vastausotsakkeet. Jos Cache-Control ei näy, palvelinmoduuli voi olla pois päältä, CDN saattaa muuttaa otsaketta tai jokin lisäosa saattaa ohittaa otsakkeet.
Esimerkkikestoja Apache-ympäristöön: CSS:lle ja JS:lle max-age=31536000, kuville max-age=31536000, PDF:lle max-age=2592000, HTML:lle max-age=0 ja no-cache. Nämä arvot ovat hyvä lähtökohta; niitä tulee muokata sivustosi julkaisurytmin mukaan. Kun käytät Hostragonsin hosting-alustalla .htaccessin kautta tehtäviä suorituskykyasetuksia, on suositeltavaa tarkistaa, etteivät ne ole ristiriidassa teeman ja lisäosien välimuistiasetusten kanssa. Apache .htaccess Suorituskykyasetukset
Selainvälimuistin asetukset Nginxillä
Nginxiä käyttävillä palvelimilla välimuistiotsakkeet määritellään server- tai location-lohkoissa. Nginxiä suositaan erityisesti paljon liikennettä saavissa projekteissa sen tarjoaman korkean suorituskyvyn staattisten tiedostojen tarjoilun ansiosta. Peruslogiikkana on määrittää expires- ja add_header Cache-Control -arvot päätteeseen perustuvalla location-säännöllä.
Esimerkkilähestymistapa: staattisille resursseille, kuten CSS, JS, WebP, JPG, PNG, SVG, WOFF2, asetetaan expires 1y ja Cache-Control public, immutable. HTML-tulosteille suositaan expires off- tai no-cache-määritystä. Jos käytät CDN:ää, sinun on myös testattava, miten CDN tulkitsee alkuperäispalvelimelta tulevat Cache-Control-otsakkeet.
Nginx-asetuksissa on huomioitava, että add_header-direktiivi koskee joissain tapauksissa vain tiettyjä vastauskoodeja. Nykyaikaisissa Nginx-määrityksissä voidaan käyttää always-parametria. Lisäksi, jos sama otsake lisätään sekä sovelluksessa, Nginxissä että CDN:ssä, voi syntyä ristiriitaisia tai päällekkäisiä Cache-Control-arvoja. Tällöin prioriteettiketju on selkeytettävä ja yksi lähde on määritettävä auktoriteetiksi.
Välimuistitus LiteSpeed- ja WordPress-sivustoilla
LiteSpeed-palvelimet tarjoavat vahvan suorituskykyedun erityisesti WordPress-projekteissa LiteSpeed Cache -lisäosan avulla. Selainvälimuisti ja sivuvälimuisti on kuitenkin pidettävä erillään. Kun LiteSpeed Cache -lisäosan Browser Cache -vaihtoehto aktivoidaan, staattisten tiedostojen välimuistiotsakkeet voidaan ottaa käyttöön automaattisesti. Silti kestoajat on tärkeää tarkistaa.
WordPressissä suositeltu käytäntö on välimuistittaa staattiset resurssit pitkäksi aikaa ja pitää tiedostojen versiointi aktiivisena. Kun teet teemapäivityksen, CSS-muutoksen tai JS-muutoksen, lisäosan välimuisti on tyhjennettävä, ja jos CDN on käytössä, on suoritettava CDN:n tyhjennys. Muuten osa käyttäjistä saattaa kohdata vanhan ulkoasun tai rikkinäisen JavaScript-toiminnallisuuden.
Suosituissa välimuistilisäosissa on vaihtoehtoja, kuten Browser Cache, Minify, Combine, Critical CSS, CDN-integraatio ja Object Cache. Kaikkien aggressiivinen käyttöönotto samanaikaisesti ei ole aina oikea ratkaisu. Järjestele ensin selaimen välimuistiotsakkeet ja testaa sitten minify- ja combine-asetukset. Koska HTTP/2 ja HTTP/3 ovat yleisiä vuonna 2026, jokaisen tiedoston yhdistäminen ei ole enää yhtä kriittistä kuin ennen; se voi jopa heikentää välimuistin tehokkuutta joissain tapauksissa.
Jos WordPress-sivustosi on hidas, ongelma ei välttämättä johdu pelkästään selainvälimuistista. Tietokannan paisuminen, raskas teema, liialliset lisäosat, optimoimattomat kuvat ja vähäresurssinen hosting vaikuttavat myös suorituskykyyn. Siksi välimuistiasetukset on arvioitava yhdessä laadukkaan hostingin, ajantasaisen PHP-version ja oikean SSL-määrityksen kanssa. Hostragons WordPress hosting
Miten välimuistiajat asetetaan CDN:ää käytettäessä?
CDN välittää staattiset tiedostosi käyttäjää maantieteellisesti lähellä olevilta reunalta. Selainvälimuisti puolestaan tallentaa tiedoston käyttäjän selaimeen. Kun nämä kaksi kerrosta toimivat yhdessä, suorituskyvyn paraneminen on selvempää. CDN-paneelissa määritetyn reunan välimuistiajan ja alkuperäispalvelimen Cache-Control-otsakkeiden on kuitenkin oltava yhteensopivia.
Yleinen lähestymistapa voi olla seuraava: anna alkuperäispalvelimella staattisille tiedostoille 1 vuoden Cache-Control ja määritä CDN:ssä sama tai hallittu TTL. Tiedostomuutoksissa versioi tiedostonimi tai tee CDN-tyhjennys. Jos käytät CDN-välimuistia HTML-sivuilla, luo erityissääntöjä; jätä esimerkiksi ostoskori, tili, maksu ja hallintapaneeli ehdottomasti välimuistin ulkopuolelle.
Yleinen ongelma CDN:ää käyttävillä sivustoilla on vanhojen tiedostojen näkyminen päivityksen jälkeen. Syynä on yleensä sisällön muuttaminen ilman tiedostonimen vaihtamista tai CDN-tyhjennyksen tekemättä jättäminen. Varmin menetelmä on tuottaa build-vaiheessa tiivisteellinen tiedosto ja kutsua uutta tiedostonimeä HTML:ssä. Näin uusi sivu pyytää uutta tiedostoa, vaikka sekä selain että CDN säilyttäisivät vanhan tiedoston.
Soveltamisen tarkistuslista askel askeleelta
Seuraava tarkistuslista tarjoaa käytännöllisen toteutussuunnitelman selainvälimuistin kestoajoille. Pienellä yrityssivustolla se on toteutettavissa 30–60 minuutissa; verkkokauppa- tai räätälöityjen ohjelmistoprojektien kohdalla testausaikaa on varattava enemmän.
- 1. Laadi tiedostoinventaario: Erottele CSS, JS, kuvat, fontit, PDF:t, HTML ja API-vastaukset.
- 2. Määritä päivitystiheys: Kirjaa ylös, mitkä tiedostot muuttuvat päivittäin ja mitkä kuukausittain.
- 3. Valitse versiointistrategia: Käytä tiedostonimen tiivistettä, versioparametria tai build-numeroa.
- 4. Lisää palvelinsäännöt: Määritä Cache-Control-otsakkeet Apache-, Nginx-, LiteSpeed- tai CDN-paneelissa.
- 5. Sulje pois suojatut sivut: Käytä no-store-määritystä ylläpito-, maksu-, ostoskori-, käyttäjäpaneeli- ja henkilötietosivuilla.
- 6. Testaa: Varmista toimivuus Chrome DevToolsilla, curl -I:llä, WebPageTestillä, Lighthousella ja oikeilla laitteilla.
- 7. Seuraa julkaisun jälkeen: Tarkista, esiintyykö virheellisiä vanhoja tiedostoja, rikkinäistä ulkoasua tai JS-virheitä.
Miten selainvälimuisti testataan?
Nopein tapa selvittää, toimivatko asetukset, on käyttää selaimen kehittäjätyökaluja. Avaa sivu Chromessa, siirry DevTools Network -välilehdelle, napsauta CSS- tai kuvatiedostoa ja tarkastele Response Headers -osion Cache-Control-arvoa. Toisella latauskerralla Status-sarakkeessa saattaa näkyä "memory cache" tai "disk cache".
Jos käytät komentoriviä, komento curl -I sinunverkkotunnuksesi.fi/tiedosto.css näyttää vastausotsakkeet. Täältä voit tarkistaa Cache-Control-, Expires-, ETag- ja Last-Modified-arvot. Jos odottamaasi otsaketta ei näy, jokin sovellus-, verkkopalvelin- tai CDN-kerroksista on saattanut muuttaa asetusta.
Suorituskyvyn testaamiseen voidaan käyttää Lighthousea, PageSpeed Insightsia ja WebPageTestiä. Sen sijaan, että sokeasti noudattaisit näiden työkalujen suosituksia, arvioi tilannetta todellisen käyttäjän skenaariolla. Esimerkiksi Lighthouse suosittelee staattisille tiedostoille pitkää välimuistiaikaa, mutta ei odota samaa aggressiivisuutta HTML-sivuiltasi. Lisäksi testityökalut saattavat antaa varoituksia kolmannen osapuolen skripteistä; et välttämättä voi hallita Google Fontsin, mainosverkostojen tai some-skriptien välimuistiaikoja.
Yleisimmät virheet
Vaikka selainvälimuisti vaikuttaa yksinkertaiselta, väärin määritettynä se voi aiheuttaa päivitysongelmia, tietoturvariskejä ja käyttökokemuksen ongelmia. Seuraavat virheet ovat erityisen yleisiä aloittelijoilla.
- Vuoden välimuistin antaminen kaikille resursseille: HTML:ää, API-vastauksia ja käyttäjäkohtaista sisältöä ei pidä sisällyttää tähän.
- Pitkän välimuistin käyttö ilman tiedostojen versiointia: Käyttäjät saattavat nähdä vanhoja CSS- tai JS-tiedostoja.
- CDN-tyhjennyksen unohtaminen: Vaikka alkuperä päivittyisi, CDN saattaa tarjoilla vanhaa tiedostoa.
- Päällekkäisten välimuistilisäosien käyttö: Useampi lisäosa voi kirjoittaa samoja otsakkeita aiheuttaen ristiriitoja.
- Kolmannen osapuolen varoitusten väärintulkinta: Et välttämättä voi hallita ulkoisten skriptien välimuistiotsakkeita.
- Suojattujen sivujen välimuistittaminen: Maksu- ja tilitiedoissa on käytettävä no-store-määritystä.
Suositellut lähtöarvot
Uuden sivuston turvalliset lähtöarvot voidaan tiivistää seuraavasti: CSS- ja JS-tiedostot 1 vuosi, jos ne on versioitu; kuvat 1 vuosi, usein vaihtuvat kampanjakuvat 30 päivää; fontit 1 vuosi; PDF-tiedostot 7–180 päivää päivitystiheyden mukaan; HTML-sivut no-cache tai muutaman minuutin lyhyt aika. Tämä lähestymistapa säilyttää tasapainon sekä suorituskyvyn että ajantasaisuuden välillä.
Jos sivustosi on yrityksen esittelysivusto, pitkät välimuistiajat ovat yleensä ongelmattomia. Jos kyseessä on verkkokauppa, voit antaa tuotesivun staattisille tiedostoille pitkän välimuistiajan, mutta hinta, varasto, ostoskori ja käyttäjätiedot on jätettävä välimuistin ulkopuolelle. Jos kyseessä on uutis- tai blogisivusto, voit säilyttää kuva- ja teematiedostoja pitkään ja välimuistittaa HTML-tulosteen lyhytaikaisesti julkaisutiheytesi mukaan. Verkkotunnuksesi, SSL:äsi ja hosting-infrastruktuurisi ovat myös osa suorituskykyketjua. Hostragons verkkotunnuksen tarkistus Hostragons yrityshostingratkaisut
Yhteenveto
Selainvälimuistin kestoajat parantavat merkittävästi verkkosivustosi uudelleenkäyntien suorituskykyä, kun ne suunnitellaan oikein. Perussääntö on: versioiduille staattisille tiedostoille pitkä aika, HTML:lle ja henkilötietoja sisältäville sivuille lyhyt aika tai no-store. Sama logiikka pätee Apache-, Nginx-, LiteSpeed-, WordPress- ja CDN-ympäristöissä: tunnista resurssityyppi, määritä päivitystiheys, testaa Cache-Control-otsakkeet ja jatka seurantaa julkaisun jälkeen.
Lyhyesti sanottuna selainvälimuisti on edullinen mutta vaikutukseltaan suuri nopeusoptimointi. Jos sivustoasi isännöidään Hostragons-alustalla, voit vahvistaa sekä käyttökokemusta että teknistä hakukoneoptimointia valitsemalla hosting-tyyppillesi sopivat välimuistiasetukset. Arvioidaksesi tarpeisiisi parhaiten sopivaa hosting-ratkaisua, voit tutustua Hostragonsin hosting-vaihtoehtoihin tai tarkistaa nykyisen sivustosi välimuistimääritykset askel askeleelta. Hostragons hostingpaketit
Usein kysytyt kysymykset
Mikä selainvälimuistin kestoajan tulisi olla?
Versioiduille staattisille tiedostoille, kuten CSS, JS, kuvat ja fontit, 30 päivästä 1 vuoteen on ihanteellinen. HTML-sivuilla sisällön tuoreus on tärkeää, joten no-cache, max-age=0 tai muutaman minuutin lyhyt aika on suositeltavaa.
Mitä eroa on Cache-Controlilla ja Expiresillä?
Cache-Control on moderni ja joustavampi HTTP-otsake; se käyttää sekuntipohjaisia sääntöjä, kuten max-age. Expires taas antaa tietyn päivämäärän ja kellonajan. Nykyaikaisissa projekteissa Cache-Controlia tulisi käyttää ensisijaisesti ja Expires lisätä taaksepäin yhteensopivuuden varmistamiseksi.
Miten selainvälimuisti otetaan käyttöön WordPressissä?
Lisäosissa, kuten LiteSpeed Cache, WP Rocket ja W3 Total Cache, voidaan aktivoida Browser Cache -vaihtoehto. Lisäksi .htaccess- tai palvelinmäärityksillä voidaan lisätä Cache-Control-otsakkeita tiedostotyyppien mukaan.
Eivätkö sivustopäivitykset näy, jos välimuistiaika on pitkä?
Jos päivität samaa CSS- tai JS-tiedostoa vaihtamatta tiedostonimeä, jotkut käyttäjät saattavat nähdä vanhan tiedoston. Tämän estämiseksi on käytettävä tiedostojen versiointia, tiivisteellisiä tiedostonimiä ja CDN-tyhjennystä.
Tulisiko maksu- ja käyttäjäpaneelisivut välimuistittaa?
Ei. Sivuilla, jotka sisältävät henkilötietoja, kuten maksu, ostoskori, tili, lasku ja hallintapaneeli, on käytettävä turvallisia otsakkeita, kuten Cache-Control: no-store, private. Tietoturvasta ei pidä tinkiä suorituskyvyn vuoksi.