Gzip via htaccess

[Stian O]

Fant dette lille trikset her:
10 htaccess Hacks Every SEO Should Know | Make it Rank

6. Enable gzip with htaccess

Gzip is a means of compressing the files on your server so they will load faster. To enable gzip, just

AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip

BrowserMatch bMSIE !no-gzip !gzip-only-text/html

----
I teorien skjønner jeg at dette er en god ide. Det blir fort ganske mye tekst som må loades, særlig om man har et jquery bibliotek m.m., og gzip vil redusere bruken av båndbredde betraktelig.

Men det er helt sikkert noen gode grunner til IKKE å gjøre dette også... eller ?

 

[Tonny Kluften]

Veldig bra at du nevner dette Stian O. Selv vet jeg ikke mye om emnet og hører gjerne fra andre som har peiling på akkurat dette.

 

[Pong]

Det er ihvertfall noe som w3c liker (woorank liker den også). Grunnen for meg var å validere, ikke annet.

Husker jeg jobbet for å få 123vann.no til å validere for mobil.
Fant da senere ut at Safari ikke tåler gzip på bl.a. håndheldte saker. Bummer.

 

[adeneo]

Det første man bør sjekke er vel hvilke moduler som kjører på det webhotellet man bruker, det gjør man enkelt ved å kjøre phpinfo() eller ved å benytte en av en rekke andre metoder, "print_r(apache_get_modules()); " fungerer fint for meg.

Da ser man man om serveren kjører mod_deflate eller om man kan bruke mod_gzip i stedet osv.

Dersom serveren kjører en Apache versjon som er eldre enn 2.0, så er det som regel mod_gzip som gjelder, og da gjør man noe slikt:

<IfModule mod_gzip.c>
    mod_gzip_on       Yes
    mod_gzip_dechunk  Yes
    mod_gzip_item_include file      \.(html?|txt|css|js|php|ico|swf|pl)$
    mod_gzip_item_include handler   ^cgi-script$
    mod_gzip_item_include mime      ^text/.*
    mod_gzip_item_include mime      ^application/x-javascript.*
    mod_gzip_item_exclude mime      ^image/.*
    mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</IfModule>

De fleste webhotell i dag støtter mod_deflate, og jeg bruker for tiden noe sånt:

SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|t?gz}zip|bz2|sit|rar|flv|pdf)$ \
no-gzip dont-vary
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

Som virker bra for meg i hvert fall. Man kan også hvis man er usikker legge inn en "if" :

<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
SetEnvIfNoCase Request_URI...........osv.osv.
</IfModule>

Jeg kan ikke se at det er noen gode grunner til å ikke bruke komprimering, og det skal så vidt jeg vet virke på mobile platformer også, men er noe usikker, jeg trodde alle nyere nettlesere som ikke støtter gzip ga beskjed om dette via http requests slik at innholdet automatisk ikke ble pakket før det blir sent, og kan ikke si at jeg har opplevd noen problemer med Safari spesielt.

Det står en del mer om dette på Apache sine sider!

Når det kommer til store bibliotek som du nevner, slik som jQuery, så nevner jeg det igjen jeg, men gzip brukes bare første gangen dette sendes til nettleseren, påfølgende ganger bør slike ting være cachet i nettleseren dersom caching er satt opp riktig i .htaccess og det er ikke noe behov for å sende disse dataene på nytt. Det samme gjelder hvis du bruker Google's API til å laste slike ting, da vil nettleseren til den som besøker siden din sannsynligvis allerede ha dette i cachen ettersom det er stor sannsynlighet for at brukeren allerede har besøkt en annen nettside som bruker Google's API, og har allerede cachet jQuery fra den siden, og når nettleseren ser at du linker til samme kilden så vil den bruke den versjonen som allerede ligger cachet.

 

[Eggan]

En ulempe jeg kommer på i slengen er at det vil øke CPU-bruken på serveren. Så sliter du med høy CPU-bruk er ikke så lurt, men om du heller sliter med båndbredden og vil spare denne er det bare å kjøre på!

 

[jagarock]

jeg gjør det ikke, sist gang jeg leste om dette for rundt et halvt år siden kunne det oppstå problemer innimellom. men siden det er et halvt år siden, så er det på tide med en revisjon på bruken for min del.

jeg regner med at alt er på stell og at man kan bruke det på samme måte som man kan bruke javascript, det funker i så stor grad at det kan være dumt å ikke bruke det.

 

[adeneo]

Uten at jeg har noe særlig greie på dette, så er det vel rimelig elementært.
Nettleseren sender en http forespørsel til serveren, i den forespørselen ligger en header som inkluderer noe sånt som "Accept-Encoding: gzip, deflate", og ut i fra dette vet serveren at nettleseren kan pakke ut innhold som er komprimert og sender derfor komprimerte filer som pakkes ut av nettleseren.
Dette skjer på vanlig måte, og serveren må vel ikke akkurat jobbe særlig mye hardere, den sender uansett ut en 200 melding først og så de nødvendige filene, uansett om de er komprimert eller ikke, det er vel nettleseren som tar jobben med å pakke dette ut igjen?

Gzip har vel vært fullt støttet siden IE4 og de tidligste Netscape nettleserene, og siste nettleser som hadde tidvis problemer med komprimert innhold var vel den høyt elskede IE6, men dette ble rettet i service pack 1 til IE6, og problemet oppsto kun en sjelden gang, så kan ikke se at det skulle være noe problem å bruke gzip.
Google, Yahoo, Microsoft og omtrent alle store nettsider som finnes på nettet bruker dette, så tror ikke det er noe å bekymre seg nevneverdig over?

Edit: Legger til at på enkelte typer sider så kan vel faktisk cpu bruken på serveren gå i taket hvis man benytter gzip modulen, men dette er helt spesielle tilfeller hvor sidene er svært dynamiske og må pakkes av serveren på nytt for hver forespørsel, noe som ikke er tilfelle for de aller fleste statiske nettsider, hvor bruk av gzip normalt ikke fører til nevneverdig cpu bruk.