Welcome to WebmasterWorld Guest from 54.196.232.162

Forum Moderators: Ocean10000 & incrediBILL & phranque

Message Too Old, No Replies

gzip mod deflate

     
1:47 pm on Jan 6, 2011 (gmt 0)

Junior Member

5+ Year Member

joined:Jan 18, 2010
posts: 127
votes: 0


Hi,

I've been reading up on this and I've been trying out a fair few different .htaccess solutions for my problem but to no avail.

My "problem" is that I want to compress html, css, php, xml, js and maybe images when people send a request to my server AKA visit my website.

Every "solution" I find, doesn't seem to work. As in, nothing get's compressed.

For instance I tried:

<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file \.(html?|txt|css|js|php|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>

and:

# compress text, html, javascript, css, xml:
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

# Or, compress certain file types by extension:
<Files *.php>
SetOutputFilter DEFLATE
</Files>

But the results are the same, nothing is compressed. If I turn on gzip compression in Joomla the only thing that get's compressed is the basic HTML that's requested. CSS, etc.. isn't compressed.

There are several websites that you can use to "check" if you compress your content and they say my website is actually sending compressed files on request but Yslow or Page Speed tell a different story.

I'm using Joomla and I enabled gzip. It works on some files but on most it doesn't.
I tried installing extensions that do can do this for you, but they don't work flawless. They compress to much and/or in the wrong order which breaks javascript etc..

I looked into google's mod_pagespeed but that's to much Beta at the moment for my liking. Plus I'd need my host to work with me to get it installed and I can't "test" it before I install it. I'd like to test it and make sure my website doesn't break by installing a apache module.

I contacted my host about my compression problems, but they react in a fashion where this isn't a problem and fixing it should be common sense. I however lack the "common sense" to sort this out. So any help is greatly appreciated (:
3:58 pm on Jan 14, 2011 (gmt 0)

Junior Member

5+ Year Member

joined:Jan 18, 2010
posts: 127
votes: 0


Hi Jim,

Cheers for the bump.

I'm getting more and more confused. I have 2 websites at the same host. One is running on Direct Admin the other one is cPanel. Direct Admin works, cPanel doesn't. Even my host has difficultly figuring it out. That could of course mean I have a crappy host (:

Anyway, I spoke to 2 different tech support guys today from my host. According to them, the problem lies with cPanel. Atleast that's there best guess so far. Does anyone know if cPanel is hard(er) to configure when it comes to compression?
4:23 pm on Jan 14, 2011 (gmt 0)

Administrator

WebmasterWorld Administrator coopster is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:July 31, 2003
posts:12533
votes: 0


There are several websites that you can use to "check" if you compress your content and they say my website is actually sending compressed files on request but Yslow or Page Speed tell a different story.


If you are using an antivirus (and/or firewall combination) program, are you certain they are not clipping your compression request headers before the request is sent? You can use the LiveHttpHeaders plugin for Firefox to be certain.
4:26 pm on Jan 14, 2011 (gmt 0)

Junior Member

5+ Year Member

joined:Jan 18, 2010
posts: 127
votes: 0


I'm using:

Live HTTP Headers
YSlow
and Page Speed

I also use websites to check if compression is on. It's not that compression doesn't work at all. The problem is that only the HTML is being compressed. There's no compression on javascript or css files. Sorry if that wasn't clear enough.
4:39 pm on Jan 14, 2011 (gmt 0)

Administrator

WebmasterWorld Administrator coopster is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:July 31, 2003
posts:12533
votes: 0


OK. Then it may be the version of Apache you are running. Here is some further reading if you have not already absorbed the Apache docs on >= 2.1 and filtering:

AddOutputFilterByType Compatibility:
Available in Apache 2.0.33 and later;
deprecated in Apache 2.1 and later


[httpd.apache.org...]
[httpd.apache.org...]
11:58 pm on Jan 27, 2011 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Apr 20, 2004
posts: 1475
votes: 0


My "not being compressed" issue (using mod_deflate) seems to involve requests with a query string appended, as Drupal does with every .css and .js file. Here's some LiveHttpHeader output (with irrelevant clutter removed):

http://example.com/

GET / HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate

HTTP/1.1 200 OK
Server: Apache/2.2.15 (Fedora)
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
----------------------------------------------------------
http://example.com/modules/node/node.css?n

GET /modules/node/node.css?n HTTP/1.1
Accept: text/css,*/*;q=0.1
Accept-Encoding: gzip,deflate

HTTP/1.1 304 Not Modified
Server: Apache/2.2.15 (Fedora)
Vary: Accept-Encoding,User-Agent

Note that the first request for the index file IS compressed, while the second request for a css file with a tiny query appended is NOT compressed.

Just adding to the pile. I don't find any restrictions on query strings in the Apache docs.
12:53 am on Jan 28, 2011 (gmt 0)

Senior Member

WebmasterWorld Senior Member 5+ Year Member

joined:June 14, 2010
posts:985
votes: 0


Here's what I have applied on my server and it works like a charm. Very small script. Note that this is for mod_deflate as opposed to the older version mod_gzip and assumes that you know it's loaded; if not then adjust it by enclosing it in a <IfModule mod_deflate.c> otherwise just as is below should work fine:

<FilesMatch "\.(php|css|html?|xml|txt|js|pl)$">
SetOutputFilter DEFLATE
</FilesMatch>


I have this applied in the httpd.conf file, I'm not sure if you need to vary it slightly for use in .htacess -- maybe someone else can jump in and assess it.

It's probably better to list the extensions in the order that you know are the most frequently accessed. Also, do not add image files to compression because they are already compressed and it could actually make it worst and slow things down.

Oh yeah and don't forget to reload your configuration file afterward.
7:36 am on Jan 28, 2011 (gmt 0)

Junior Member

5+ Year Member

joined:Jan 18, 2010
posts: 127
votes: 0


I contacted my host and they rebuild apache with mod_deflate properly configured and now it works. Thanks for all the suggestions.
5:39 pm on Jan 28, 2011 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Apr 20, 2004
posts: 1475
votes: 0


Excellent! Thanks for that, SevenCubed. In my Drupal case, it seems that Drupal was handling those files, and when I activated compression in the Performance section of its management interface, .css and .js files were compressed properly.
5:47 pm on Jan 28, 2011 (gmt 0)

Administrator

WebmasterWorld Administrator coopster is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:July 31, 2003
posts:12533
votes: 0


Also, you're second request example would not be compressed because no content is returned therefore nothing to compress:

Note that the first request for the index file IS compressed, while the second request for a css file with a tiny query appended is NOT compressed.
HTTP/1.1 304 Not Modified 
Server: Apache/2.2.15 (Fedora)
Vary: Accept-Encoding,User-Agent
9:37 pm on Jan 28, 2011 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Apr 20, 2004
posts: 1475
votes: 0


I think the 304 status message indicates that the content was simply not modified by the server on its way out. Please correct me, if I'm wrong.

I know for sure that the file was received, along with all of the other .css and .js files that indicated the same status in LiveHttpHeaders.
10:58 pm on Jan 31, 2011 (gmt 0)

Senior Member

WebmasterWorld Senior Member jdmorgan is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:Mar 31, 2002
posts:25430
votes: 0


It means that that content has not been modified since the date that your browser sent in its IF-Modified-Since request header, and that therefore, your browser should simply render the copy of that content that is already in its cache.

There's no use using a headers checker without this:

[w3.org...]

Jim
6:10 pm on Feb 1, 2011 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Apr 20, 2004
posts: 1475
votes: 0


I was using this reference: [w3.org...]

I have always read that to mean that if the client has already cached the file, then it must use the cached copy, however if the client has not cached it yet, then the client makes a second request and the server delivers it. I was responding to the note that "second request example would not be compressed because no content is returned therefore nothing to compress", which ends up being true in my case, as I had already cached the file. I f I had not yet cached the file, then, you're right, there would have been a second request with a different result code.

Sorry for the confusion.
7:36 pm on Feb 7, 2011 (gmt 0)

Senior Member

WebmasterWorld Senior Member jdmorgan is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:Mar 31, 2002
posts:25430
votes: 0


If the response is 304-Not Modified, then the server never invokes any content-handling at all. Therefore, the compression function won't be invoked (it certainly shouldn't be, since there is no content).

It's important to understand the subtleties here: The 'decision factor' is not whether the client has cached the content in a general way, it is whether the client sent an If-Modified-Since header with its request that indicates a date that is *after* the most recent change to the resource on the server.

If the last-modified date of the version cached by the client is older than that stored on the server, the server will send the new version with a 200-OK status. The client will then cache that, along with the new Last-Modified date returned by the server.

If the version cached by the client is still current, then the server sends back a 304-Not Modified response and terminates the transaction without invoking any content-handling.

Jim
8:27 pm on Feb 7, 2011 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Apr 20, 2004
posts: 1475
votes: 0


Thanks. That makes perfect sense, to me.
 

Join The Conversation

Moderators and Top Contributors

Hot Threads This Week

Featured Threads

Free SEO Tools

Hire Expert Members