v1.1.0 released

• Achievements page was added. We are introducing new concept of website speedup - speedup achievements. Now every user can get how its website is fast in terms of industry standards / evaluations and measure website performance through time. For this purpose there is Achievements page inside the product and its external copy to share with your friends, colleagues, or even boss :) More info about WEBO Site SpeedUp awards.
• Improved caching / gzip for some systems.
• Improved server modules detection (CGI environment).
• Improved UI (a lot of minor fixes to make it easier).

WEBO Site SpeedUp v0.9.7

We are moving to completely stable and featured v1.0 and here is one more update on this way. In the version 0.9.7:

• Improved UI. All icons were recreated and combined to a few of CSS Sprites (via Auto Sprites tool). Now the whole interface loads faster and there are less files in package (update is going also faster).
• Added option to exclude WEBO Site SpeedUp logic. You can define in System Status -> Settings a number of parts of URL to exclude from processing - and they won't be accelerated with WEBO Site SpeedUp. This field has the same syntax as for Server Side Cache exclude option.
• Improved smush.it callbacks. Reviwed some more issues with bunch image optimization of a huge amounts of data. Callbacks from smush.it tuned a bit.
• Improved static gzip tool. Now it can use gzip console tool if it's allowed to be executed from PHP.
• Improved CSS Sprites logic. Fixed a minor issue with ancesting seletroes lookup and improved CSS Tidy merging qualities.
• Improved gzip on CGI enviroments for CSS/JavaScript files.
• Fixed minor compatibility issues.

Download new version from here or just update it from your product interface.

Static gzip is your best friend

After we touched several aspects of caching let's return to gzip and review very simple and powerful technique 'Static gzip'.

What is Static Gzip?

Static Gzip is a way to serve compressed content w/o its actual compression 'on fly' (here is a blog post about gzip). Very roughly we have gzipped files and serve them instead of common ones. How can we do this?

General algorithm

• First of all we need to have gzipped versions of initial files. Usually they are named with a postfix .gz, i.e. main.css.gz. As far as these files are static we can have them compressed at maximum. With Linux you can do the following

  gzip -c -n -9 main.css > main.css.gz

  to get the smallest compressed file from the initial one.
• Secondly we must have any way to route HTTP requests to take compressed version of the file. Via Apache and mod_rewrite we can add the following rules to .htaccess file or Apache configuration.

  <IfModule mod_rewrite.c>
   RewriteEngine On
   RewriteCond %{HTTP:Accept-encoding} gzip
   RewriteCond %{HTTP_USER_AGENT} !Konqueror
   RewriteCond %{REQUEST_FILENAME}.gz -f
   RewriteRule ^(.*)\.css$ $1.css.gz [QSA,L]
   <FilesMatch \.css\.gz$>
    ForceType text/css
   </FilesMatch>
  </IfModule>
  <IfModule mod_mime.c>
   AddEncoding gzip .gz
  </IfModule>

Rip off the veil of the mystery

What does this set of rules actually do?

• First of all we enable RewriteEngine (it may have been already enabled in your configuration).
• Then

  RewriteCond %{HTTP:Accept-encoding} gzip

  rule selects all HTTP requests with

  Accept-Encoding: gzip

  header and allows Apache to perform other rules.
• Then we skip Konqueror browser

  RewriteCond %{HTTP_USER_AGENT} !Konqueror

  because it seems it doesn't understand compressed content for CSS / JavaScript files.
• Then we check if there is physical file with postfix .gz

  RewriteCond %{REQUEST_FILENAME}.gz -f

• And only after all these checks we perform actual internal rewrite rule.

  RewriteRule ^(.*)\.css$ $1.css.gz [QSA,L]

  We redirect all requests to .css files to .css.gz files.
• After this redirect (which is the last one — modificator [L]) we force Content-Type of such files to be text/css. Most servers send .gz with default archive encoding, and browsers can't properly detect this content.
• Finally with AddEncoding gzip .gz rule sets proper Content-Encoding header for compressed content.

Of course this logic can be applied not only to CSS files but to all files which can be efficiently compressed — JavaScript, fonts, favicon.ico, etc.

That's all?

Graceful Degradation

What if Apache doesn't have mod_rewrite module? Or we need to serve CSS content via PHP? Or there is environment which doesn't support such logic (CGI / IIS)?

Well we can perform the whole algorithm actually via PHP too. All what we need here is the following.

• Form compressed file name (usually just with a postfix .gz). And check for this file's existence.
• If no such file exists, create compressed version of the file (i.e. via gzcompress function).
• Then write this compressed content to a new file (with already defined 'gzipped' file name).
• And set for this file time of change (mtime) to the value equals to initial (non-compressed) one. Why it's required? Because we can with check for existence also check if gzipped version of the current file has the same mtime and skip its re-creation in case of equivalence. If the current file and its compressed version have different time of change — it seems we need to re-create latter.

So with this logic we just check for file's existence and perform 2 checks for mtime (all such checks can be cached on file system level, or cache folder can be mapped to shared memory) and serve gzipped version. CPU is saved (with 80-85% of transferred content size)!

So Web Optimizer has all such approaches integrated and with version 0.6.7+ allows you to create .gz versions of CSS / JS files within any folder on your website.

Gzip challenges: browser compatibility, static gzip, graceful degradation

GZip (GNU Zip) is the most fundamental way to compress information in web. It exists for a decade (or more) and is supported today almost by every agent (browsers, robots, parsers, etc). So how can it used?

The first challenge: to gzip or not to gzip?

Well, it's OK to gzip every textual content on your website. But there were (or are) a few troubles with old versions of IE (which didn't understand this Content-Encoding), Safari (with gzip for CSS/JS files), and other browsers. All of they can be prevented (more or less), but their existence stop developers and admins from using this techniques through their projects and websites. Moreover there are a few less documented issues with some proxy servers, Content-Encoding, and chunks, which can lead to the whole server shutdown (implementation bugs). So should we use gzip?

We must! Gzipped content is usually 50-85% less in size, and this tremendously helps in accelerating your web pages. So let's review what ways are to prevent known bugs. For IE6 we can use these approaches:

• not gzip if there is no SV1 in User Agent string (Service Pack 1, which has some issues with gzip fixed),
• add 2048 spaces in beginning of gzipped file,
• or just use deflate (with content flushing) instead of gzip.

To prevent issues with Safari (and some other browsers) we can just force Content-Type for gzipped content according to its initial value.

So most of the troubles can be solved.

The second challenge: CPU overhead

Also gzip adds very little to actual server processing time, but if you use powerful caching systems, proxing, etc, it can be notable. Here we come with static gzip.

Static gzip is a way to store gzipped content somewhere (usually on a hard disk, but it can be also any memory cache), so we cache gzip results and show them to end users, saving CPU time.

All works well here? Actually, no. But it's...

The third challenge: graceful degradation

No Apache / web server support for static gzip. Sometimes we can use any static gzip directives (i.e. special mod_rewrite ones) to redirect initial requests from static (or cached) files to their gzipped versions. Classical example is this mod_rewrite usage

RewriteCond %{HTTP:Accept-encoding} gzip
RewriteCond %{HTTP_USER_AGENT} !Konqueror
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule ^(.*)\.css$ $1.css.gz [QSA,L]
<FilesMatch \.css\.gz$>
 ForceType text/css
</FilesMatch>

Here we check if user agent supports gzip encoding, if it's not Konqueror (which doesn't understand gzipped CSS/JS files), and if a statically gzipped file (.css.gz) exists. After this we redirect (internally) request to this file and force correct Content-Type for it.

But what if there is no mod_rewrite support? No problem! We can do the same a light PHP proxy, which actually receives a request, checks for all conditions, and serves prepared file.

The last challenge: what to gzip?

This one is the easiest. Obviously we need to gzip text types (XML, HTML, CSS, JS) and don't touch graphics or media files. But what else can be gzipped?

Some articles in this area recommend to add to gzipping ICO file type (which can be 3 times lesser after compression), and some font types (SVG, which is actually XML, OTF, TTF, EOT). All of this is already handled by Web Optimizer (.htaccess rules for all file types, PHP proxy with static gzip, etc). All in one brilliant acceleration package.