Kahdeksan vinkkiä Kivan omasta nettisivuprojektista

Sivustouudistuksemme keskeinen tavoite oli kehittää sivuston latausnopeutta. Tähän ei kuitenkaan ole olemassa salaista kastiketta, vaan kikkapakassa on useita työkaluja, joita yhdistelemällä saa aikaan erinomaisia tuloksia.

Saimme sivuston latautumaan keskimäärin alle sekunnissa hyödyntäen useita eri tekniikoita.

Koodit tässä tässä artikkelissa koskevat Apache-verkkopalvelinta ja ovat esitetty vain esimerkkeinä. Samat asiat löytyvät myös muista verkkopalvelimista, mutta niille on annettava eri loitsut.

Tärkeää! Älä lisää palvelimen asetuksiin mitään, mistä et ymmärrä, sillä se voi vaarantaa verkkopalvelun sekä käyttäjien tietoturvan!

Lue myös artikkeli sivustouudistuksestamme

Kivan uudet WordPress kotisivut

Kuvien optimointi: pieni on kaunista

Kuvien optimoinnilla saadaan yleensä suurin hyöty sivujen nopeuden optimoinnissa.

Nyrkkisääntönä on käyttää pakattuja kuvaformaatteja, kuten JPG, pakkaamattomien (GIF, PNG) sijaan ja pitää kaikki kuvat alle 100 kb! Ja lopuksi karsia niiden laatua niin pieneksi että lähes ahdistaa.

Olemme pyrkineet käyttämään sivustolla mahdollisimman pieniä kuvia. Jos sivustolla tarvitaan täysikokoisia kuvia, niihin linkataan eikä niitä ladata oletuksena selaimeen.

Selainvälimuisti hyötykäyttöön

Pienillä muutoksilla verkkosivuja ylläpitävän palvelimen asetuksiin on mahdollista ottaa käyttöön nk. selainvälimuisti.

Kun käyttäjä menee ensimmäisen kerran sivustolle, ladataan fontit, tyylilehdet, kuvat ja skriptit käyttäjän selaimeen. Kun välimuisti on käytössä, selainta pyydetään jemmaamaan käyttäjän tiedot. Kun sivulla navigoidaan tai käyttäjä palaa sivustolle, ei tietoja ladata palvelimelta vaan käyttäjän selaimen välimuistista.

Selainvälimuistin käyttöönotto .htaccess tiedostolla

Tässä esimerkissä on tiedostotyypeittäin säännöt kauanko käyttäjän selaimen halutaan hilloavan ladattuja tietoja välimuistissa.

Näillä säännöillä sivujen osia pidetään jemmassa vuosi vierailusta, mahdolliset CSS muutokset menee käyttäjille läpi kuukaudessa. Sisällöt ja muut tiedot on välimuistissa 2 päivää. Nämä kannattaa katsoa läpi sen kanssa kuinka usein sivustolla olevia tietoja päivitetään.

#### Selainvälimuisti ####
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/vnd.microsoft.icon "access plus 1 month"
ExpiresByType font/woff2 "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType text/x-javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresDefault "access plus 2 days"

Sivujen GZIP pakkaus nopeuttaa tiedonsiirtoa

HTML on kieli, jossa on paljon toistuvia tägejä ja html-tiedostot menevät yleensä hyvin pieneen tilaan, kun ne pakataan.

Palvelinpuolen GZIP-pakkaus tekee juuri sen miltä kuulostaakin. Kun käyttäjän selain pyytää palvelimelta ”saisinko etusivun”, lähtee samalla header-tieto, jossa selain kertoo palvelimelle mitä pakkausta se tukee.

Jos käyttäjän selain tukee gzippiä, vetää selain pyydetyn nettisivun zip-pakettiin, joka lähetetään selaimelle, joka sitten purkaa tiedoston ja näyttää sivun. Jos selain ei ilmoita tukevansa gzippiä, antaa selain normaalin, pakkaamattoman sivun.

Pakkausta kannattaa hyödyntää html, php, js, ja css tiedostoille. Valmiiksi pakatut sisällöt kuten jpeg-kuvat kannattaa jättää pois pakkauksen piiristä, koska pakattu tiedosto ei yleensä pakkaannu enää pienenpään tilaan, ja pakkaamiseen ja purkamiseen kuluu aikaa.

GZIP-pakkauksen käyttöönotto .htaccess tiedostolla

#### GZIP Pakkaus ####
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

Javascriptin ja CSS minimointi

Verkkosivustot koostuvat yleensä suuresta määrästä toiminnallista koodia, sekä tyylimäärittelyjä. WordPressissä teema tuo peliin omat tyylilehtensä ja lähes jokainen lisäosa omansa.

Tästä seuraa se, että kun käyttäjä lataa verkkosivun selain joutuu hakemaan kymmeniä lyhyitä koodinpätkiä eri css- ja js-tiedostoista.

Yhdistämisessä suurin osa näistä koodeista vedetään yhteen tiedostoon. Tällöin selain lataa vain yhden, jokseenkin isomman css ja js -tiedoston muutaman kymmenen sijaan.

Minimoinnissa näistä tiedostoista poistetaan toiminnan kannalta turhat merkit, kuten kommentit ja rivinvaihdot. Edistyneemmässä minimoinnissa voidaan koodia optimoida latautumaan nopeammin esimerkiksi muuttujien nimiä lyhentämällä.

Käytämme sivustollamme Fast Velocity Minify lisäosaa, joka niputtaa lähes kaikki tyylilehdet sekä javascriptin yksittäisiin staattisiin tiedostoihinsa ja minimoi ne.

Staattisten HTML-sivujen antaminen käyttäjille (palvelinvälimuisti)

WordPressille on saatavilla useita välimuistilisäosia (cache). Käytämme sivustollamme WordPressin kehittäjän tekemää WP Super Cache lisäosaa joka toimii suurinpiirtein näin:

Kun käyttäjä pyytää normaalisti sivua WordPressiltä, sivu kasataan tietokannasta löytyvistä paloista ja annetaan html-tiedostona käyttäjälle. WP Super Cache tallentaa tämän html-tiedoston palvelimelle (välimuistiin) ja kun seuraava käyttäjä kysyy samaa sivua, hänelle annetaan valmiiksi kasattu staattinen html tiedosto eikä sivun rakentamiseen ja tietokantakyselyihin kulu aikaa.

Yksinkertaisille sivuistoille, kuten Kivan sivusto tämä on erinomainen strategia nopeuttaa sivuston toimintaa.

Dynaamisilla sivuilla, kuten verkkokaupoilla lukuisine tuote-kategoria-koko-väri sivujen ja valikoiden, sekä niiden yhdistelmien kanssa välimuistittaminen on hieman haastavampaa, mutta ei mahdotonta.

Sisältöjen esihaku

Sisältöjen esihaku (eng. prefetching) mahdollistaa seuraavien oletettujen sisältöjen lataamisen selaimen välimuistiin, sillä aikaa kun käyttäjä silmäilee alkuperäistä sisältöä. Tästä on hyötyä, kun sivustolla on selkeitä putkia (esim. ostoskori-kassa-kiitos), joissa käyttäjät liikkuvat.

Dataohjatun liiketoiminnan rautaisena tekijänä hyöynnämme tässäkin verkkoanalytiikkaa. Sivustollamme on selkeitä käyttäjäpolkuja, joita käyttäjät kulkevat.

Esimerkiksi etusivultamme liikutaan yleensä katsomaan yrityksemme tietoja sekä tiimiä. Nämä sivut esiladataan, kun selain saa etusivun valmiiksi.

Kun käyttäjä sitten navigoi etusivulta kohdesivulle, sivu aukeaa saman tien eikä latautumista tarvitse odotella.

Prefetch esimerkkikoodi

<link rel="prefetch" href="https://www.kiva.fi/tiimi/">

DNS-esihaku

Sivustollamme käytetään muutamia kolmannen osapuolen palveluita kuten Google Analytics. Aina kun haetaan tietoja toisesta domainista (tässä tapauksessa https://www.google-analytics.com) joutuu selain tekemään DNS-haun: ”mikä tää google oikein on?”.

Kun sivuston headissa on dns-prefetch linkki, selain selvittää tuon verkko-osoitteen etukäteen taustalla. Kun myöhemmin sivulla halutaan ladata Google Analytics -skripti, selain tietää jo miltä palvelimelta kysellä! Jälleen säästimme sekunnin murto-osia.

<link rel="dns-prefetch" href="https://www.google-analytics.com">
<link rel="dns-prefetch" href="https://www.googletagmanager.com">

Tietoturva

Suojelemme sivustomme käyttäjiä haitallisilla skripteiltä sekä man-in-the-middle hyökkäyksiltä käyttämällä tiukkoja tietoturvasääntöjä.

Sivustollamme ei tarvita webkameraa eikä mikrofonia, selainta siis kielletään käyttämästä kyseisiä palveluita käyttäen nk. security headereita.

Voit tarkistaa sivustosi tietoturva-headerit esimerkisi tällä työkalulla:
https://securityheaders.com/

HTTPS ja SSL sertifikaatti

Kun palvelimella on SSL-sertifikaatti, voidaan käyttää HTTPS-protokollaa, jolloin kaikki tieto kulkee selaimen ja verkkopalvelimen välillä salattuna. Käytännössä edes teleoperaattorit joka verkoissa tietosi kulkee, tai NSA* ei pääse verkkoliikenteesi käsiksi.

HTTPS:n käyttämä SSL-salattu liikenne tekee man-in-the-middle hyökkäyksistä käytännössä mahdottomia.

* Murtamisessa on aivan hirveä vaiva, valtion virastotkaan tuskin lähtee hyökkäämään SSL-salattua liikennettä vastaan ilman erittäin painavaa syytä.

SSL:n käyttöönoton jälkeen on tärkeä ohjata käyttäjät http- alkuisista osoitteista https- alkuisiin osoitteisiin, jolloin heidän liikenteensä salataan. Tämä on kriittisen tärkeää myös hakukoneiden kannalta, jotta sivustosta ei indeksoidu molemmat versiot.

http –> https uudelleenohjaus .htaccess tiedostolla

#### HTTP --> HTTPS redirect ####
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Pakottaa HTTPS:n käyttöön seuraavaksi vuodeksi myös alidomaineihin
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS

Tietoturvaheaderit

Kun selain kysyy palvelimelta esimerksi verkkosivun tai kuvan, vastaa palvelin siihen headereilla, ja sen jälkeen pyydetyllä sisällöllä. Näihin headereihin voidaan kirjoittaa sääntöjä, kuten ”älä lataa sisältöjä mistään muualta kun meidän palvelimelta” mikä vaikeuttaa esimerkiksi salasanojen haistelua sivustolla merkittävästi.

Security headerit .htaccess tiedostolla

#### Security headers ####
# Älä salli sivun näyttämistä iframessa
Header set X-Frame-Options "SAMEORIGIN"

# Estä mime-tyyppien haistelu
Header set X-Content-Type-Options "nosniff"

# Älä lähetä referrer-tietoa paitsi omille sivuille
# Huom: Tärkeä analytiikalle!
Header set Referrer-Policy "same-origin"

# Poista sivustolla turhia ominaisuuksia käytöstä, joita hyökkääjä voi tavoitella
Header set Feature-Policy "microphone 'none'; geolocation 'none'; camera 'none'; payment 'none'; autoplay 'none'"

Content policy .htaccess tiedostolla

Sivustollamme on määritetty content policy, joka toimii yhdenlaisena valkoisena listana mistä eri asioita voidaan ladata sivustolla.

Vääränlainen content policy voi rikkoa sivuston pahasti, joten sen suunnitteluun on hyvä varata aikaa. Tässä esimerkissä sallitaan tyylien ja skriptien lataaminen riviltä (inline) sekä omalta palvelimelta (self) kun se tapahtuu https:n yli, sekä muutamia erikseen listattuja kolmannen osapuolen palveluita.

# Määrittää mistä asioita saadaan ladata.
Header set Content-Security-Policy "default-src 'self' https:; script-src 'self' 'unsafe-inline' 'unsafe-eval' www.google-analytics.com www.googletagmanager.com tagmanager.google.com; style-src 'self' 'unsafe-inline' tagmanager.google.com; img-src 'self' data: www.google-analytics.com; font-src 'self' data: "

# www.googletagmanager.com = Google Tag Manager skripti
# tagmanager.google.com = Google Tag Manager esikatselu ja CSS
# www.google-analytics.com = Google Analytics skripti ja tracker kuva

Tämän content policyn voimassa ollessa sivulla voidaan ladata Tag Manager sekä Google Analytics, mutta mikäli esimerkiksi HotJar ladataan Tag Managerin kautta, ei sitä ole erikseen sallittu content policyssä ja tämän vuoksi käyttäjän selain estäisi HotJarin latautumisen.

Tämän vuoksi verkkomarkkintia tai konversio-optimointia tekevän henkilön on päästävä käsiksi myös palvelimen .htaccess tiedostoon normaalin GTM-pääsyn lisäksi.

.htaccess tiedoston muokkaus vaatii taitoa ja ymmärrystä, siellä tiedostolla on mahdollista saada koko sivusto tiputettua verkosta. Tämän takia sitä kannattaa editoida aina suoraan palvelimelta esimerkiksi ftp:n ylitse, eikä esimerkiksi WordPressin kautta pluginilla, koska kirjoitusvirheen sattuessa virhettä ei pääsisi korjaamaan!