Snabbare hemsidor med komprimering

Under servicefönstret natten mellan 3-4/12 genomfördes ett flertal uppgraderingar och förbättringar i vår tekniska miljö. Vi berättade t ex igår om hur alla våra webbhotellskunder nu enkelt kan ansluta säkert till sin server hos oss.

En annan uppdatering, som vi vill lyfta fram lite extra, är den nya serverkomprimeringen.

På vanlig svenska så innebär komprimering att filer minskas i storlek, för att snabbare kunna laddas ned. Jämför det t ex med en zip-fil som är komprimerad. Snabbare hemsidor är väldigt bra, både för besökare och sökmotorer.

Linuxbaserade webbservrar hos oss har nu följande aktiverat (som standard):

Apache-modulen mod_deflate komprimerar nu allt statiskt material (HTML, CSS, JS osv) mellan server och besökare. Det är en väldigt effektiv komprimering, som kan minska storleken på dessa filer med uppåt 70 %. För att stänga av denna komprimering, lägg in följande rad i en .htaccess-fil:

SetEnv no-gzip 1

PHP-modulen zlib.output_compression utför motsvarande komprimering av PHP-filer. Filerna komprimeras med gzip, vilket alla moderna webbläsare hanterar utan problem. Om man vill stänga av denna komprimering så kan man lägga in följande rad i en .htaccess-fil:

php_flag zlib.output_compression Off

Detta kan vara en bra idé om man redan komprimerar sin hemsida på egen hand, t ex via WordPress-tillägg eller liknande.

Uppdatering 2014-05-21: Ytterligare optimeringar har skett i vår servermiljö för att serverkomprimeringen inte ska påverka webbplatser med WordPress. Man behöver således inte längre lägga in ovanstående kod om man komprimerar sin hemsida via WordPress-tillägg.

Den nya serverkomprimeringen har testats framgångsrikt av våra tekniker under en lång tid innan detta servicefönster. De fann att komprimeringen gav riktigt bra resultat och hastighetsförbättringar, utan större fel. Merparten av våra kunder bör kunna notera en skillnad i hastigheten på deras hemsidor med denna serverkomprimering.

Om ni upplever något problem med er hemsida, som ni tror kan bero på den här uppdateringen, inaktivera då zlib.output_compression enligt ovan. Om problem kvarstår, kontakta vår kundtjänst för snabb hjälp med detta.

Lämna gärna en kommentar om denna uppdatering här nedan.

You Might Also Like
16 Comments
  • Patric
    says:

    Hej, själv får jag det här meddelandet i tillägget: ( PHP komprimerar data som sänds till besökare på din webbsida. Det
    rekommenderas att stänga av det eftersom tillägget sparar det
    komprimerade utdata en gång i stället för att komprimera samma sida om
    och om igen. Se också #21 på felsökningssidan. Se denna sida för instruktioner hur du ändrar din php.ini.)

    Koden som rekommenderas i htaccess löser inte heller problemet, utan då skriker programmet till att jag även måste klistra in koden i en annan accessfil till i mappen contentmappen/supercache.
    Nä, mycket jobb för inget som funkar för min del. Ställer därför samma fråga som B Sennebrink.

    • sulo
      says:

      Hej Patric, jag fick exakt samma meddelande i WP Super Cache. Det försvann dock när jag la in ovanstående inaktivering av zlib.output_compression. Det är egentligen inget problem eller fel, utan bara information om hur detta tillägg sparar filer i en cache medan serveroptimeringen komprimerar filer “on the fly”.

      Det brukar i regel räcka med att man lägger in deaktiveringen i den .htaccess-fil som ligger i rotmappen (eftersom reglerna “ärvs” nedåt). Men om tillägget säger att du ska lägga in koden på andra ställen så får du nog göra även det.

      Vi får tacka för din åsikt, den uppskattas här. Vi håller som sagt på att utvärdera denna optimering.

  • Björn Sennbrink
    says:

    Jag mätte på några av min sajter och laddningstiderna ökade efter komprimeringen. Det gjorde dessutom varken till eller från att använda vad som rekommenderas i https://blogg.fsdata.se/guide-till-en-snabbare-wordpress-sida/. Ett cacheplugin var det enda som hjälpte.

    Var det här en nödvändighet, något som efterfrågats? Jag minns Varnish på City Network. Det gjorde t.ex. att det inte går att jobba på domänen vid snabba CSS-uppdateringar (ja, vi är några som gör så).

    • sulo
      says:

      De mätningar som jag har gjort visar att en inaktivering av zlib.output_compression är fördelaktigt, prestandamässigt sett, om man sedan tidigare har optimerat sin hemsida (enligt den guide du hänvisar till).

      Om man däremot inte har optimerat sin hemsida, vilket den absoluta merparten av våra kunder inte har gjort, så är den här komprimeringen till väldigt stor fördel. Snabbare hemsidor är alltid något som efterfrågas och uppskattas.

      Vi håller givetvis ordentlig koll på utvecklingen och våra kunders respons efter att vi har infört denna komprimering. En sak vi undersöker nu är t ex huruvida vi, på ett automatiserat sätt, kan avgöra om en sida redan är optimerad och då inaktivera zlib.output_compression.

      • Thomas
        says:

        Hej!
        Jag har en sajt som vi installerat en Moodle-installation på. Det är en sida som studenter världen över loggar in på. I en av de kurser vi har finns en zip-fil på cirka 195 MB som innehåller en HTML-kurs för studenterna. När jag nu laddar ner den säger den att den endast väger 0k. Det verkar funka att ladda upp och ned filer till någonstans över 100 MB men sen blir det knas. Skulle textsträngen ovan kunna lösa problemet?
        mvh
        Thomas
        ittfeducation.com

        • sulo
          says:

          Hej Thomas! Ovanstående inaktivering av zlib.output_compression hjälper nog inte i detta fall (då det avser komprimering av PHP-filer, inte zip-filer). Förslagsvis att du kontaktar vår kundtjänst, som kan höra med våra tekniker som har direkt åtkomst till er server och konto. Skapa bara ett ärende här: https://fsdata.se/support/

          • Thomas
            says:

            Ok, det har jag gjort men blev hänvisad hit av din kollega Fredrik. Jag har en kurs som startar på onsdag och det är cirka 200 kineser som skall in och plocka den här filen så det är lite brådis. Jag har kollat överallt i Moodle och har inte ändrat någonting mot när det tidigare funkade. Det går en gräns vid strax över 100 MB…någonting måste ju ha gjorts?

            Ytterligare en fråga. I .htaccess-filen, skall textsträngen ligga utanför waffbegin-waffend eller utanför eller innanför? Det finns ytterligare en i själva moodlemappen, slår den i rotmappen, dvs ärvs eller behöver jag ändra i den med?

          • sulo
            says:

            Det var en felaktig hänvisning, som jag får be om ursäkt för. Har vidarebefordrat din fråga om zip-filen till tekniker hos oss, återkommer så snart jag fått svar.

            Textsträngen kan egentligen läggas in var som helst i .htaccess-filen. Redigera den .htaccess-fil som ligger i mappen “www”.

          • Thomas
            says:

            Hej Sulo!
            Tack för ditt svar. Helt ok, det funkade inte som du så mycket riktigt sade. Värt att notera är att det inte är något korrupt med själva zip-filen, har provat att ladda upp och ned på annan webbserver utan problem. Tacksam för all (snabb) hjälp. Det funkar också upp till strax över 100 MB så någon begränsning måste sitta någonstans och det är något som ändrats nyligen.

    • sulo
      says:

      Serverkomprimeringen är mer generellt anpassad och konfigurerad, för att fungera med så många olika hemsidor och hemsidelösningar som möjligt. Om du har en specifik komprimering/tillägg för WordPress sedan tidigare så rekommenderar vi att du fortsätter med den (dvs, inaktiverar zlib.output_compression enligt ovan).

      • Tardigrade
        says:

        Med WordPress Gzip Compression får jag följande varning:

        Warning: ob_start() [ref.outcontrol]: output handler ‘ob_gzhandler’ conflicts with ‘zlib output compression’ in /home/u/u6554025/www/cliqtags.com/wp-content/plugins/wordpress-gzip-compression/ezgz.php on line 39

        Jag misstänkte något tokigt i pluginen först, men med tanke på er ändring är det ju sannolikt relaterat till det. Ska jag bara stänga av pluginen?

        Tack på förhand,

        Anders

Lämna ett svar