1. Cache statics

Caching static content (pictures, css files, javascript files) on the client’s side (in browser) means that having received static file once browser saves it in cache and doesn’t make a request to the server next time the html-document is requested. File will be taken from cache. Both sides win: client sends less requests, web site is working faster and server processes less requests. For instance, ordinary WordPress post page has over a dozen links to the static files (css files, pictures, scripts). Time spent on downloading these files exceeds time spent on downloading the post itself. Once having caching enabled the static content will be downloaded only once. While moving to the next page the only thing that will be downloaded is page itself. All static files will be taken from cache. In order to make browser cache static content, http-response must contain specific headers: Expires and Cache-Control. Those headers are set by mod_expires and mod_headers modules. For enabling caching, create .htacces file with the following content inside the static folder:

ExpiresActive On
Header set Cache-Control public
ExpiresByType image/.+  "access 15 days"
ExpiresByType text/css  "access 5 days"
ExpiresByType application/x-javascript "access 5 days"
ExpiresByType application/javascript "access 5 days"

In case there’s no such directory for static content and files are spread across folders of web site, than if you create following .htacces in the root of the site it will cache all static content on the web site by file extension:

<Files ~ \.(gif|png|jpg|css|js)>
ExpiresActive On
Header set Cache-Control public
ExpiresByType image/.+  "access 15 days"
ExpiresByType text/css  "access 5 days"
ExpiresByType application/x-javascript "access 5 days"
ExpiresByType application/javascript "access 5 days"
</Files>

This configuration makes server send http-responses to clients with information that pictures are to be cached for 15 days and scripts and css-files for 5 days.

2. Compress responses on the run

In order to save some time on loading the content, you can compress it. All modern browsers are able to receive comressed gzip-traffic. Text files (html-files, css-files, scripts, json-data) can be easily compressed and allow you to save 20-90% of traffic. Same time, music and video files can hardly be compressed as they have already be sized with special codecs. Here’s an example of enabling gzip-compression. Add the following line in .htaccess in the root of web site:

SetEnvIf (mime text/.*) or (mime application/x-javascript) gzip=9

As you can see, this configuration is quite simple. It’s enough to have all text documents (html, css files) and javascript-files compressed before going to the client’s side. It is worth saying, that server compresses responses only for those browsers, that support compressing. Browser informs server about its features through the headers of html-request.

3. Cache dynamic responses at server side

Often large amount of requests, addressed to database server, hinder the web site performance. For example, blog’s main page shows recent entries, recent comments, navigation menu, category list and tags. Those are several complicated requests to database. In case that information does not change often or the relevance is not vital, html-responses need to be cached without hesitation. You can choose to cache the blog’s main page once in 5-10 minutes. But that would be enough to improve main page performance in browser. Practically, application developer must decide what pages need to be cached and for how long. Also he needs to bring into life caching mechanism “out of the box” . Unfortunatelly, that doesn’t happen most of the time. Likely, mod_cache in Helicon Ape will simply and easily allow you to enable caching at server side. mod_cache supports two types of cache: disk cache and memory cache. First type saves caches data on the drive, and the second one does on memory. Memory caching is more preferable. If your server doesn’t have enough RAM, use disk cache. For example, to cache site’s homepage, we need to add the following lines in .htaccess in the root:

Header set Cache-Control public,max-age=600
SetEnvIf request_uri ^/$ cache-enable=mem

This configuration enforces caching of site’s homepage request for 10 min (600sec). Response are cached in memory. Be careful! You need to enable caching carefully. For example, pages that need authentificaton mustn’t be cached as they contain private data and need to provide different information for different users. In any cases, caching must be taking application logic into account. We’ve reviewed three simple steps for increasing the speed of your web site. Besides tangible speed-boost, which you will notice at once, the acceleration must well enhance your rating in search engine results. You can see performance graph of www.helicontech.com made using Google Webmaster tools after a simple optimization. So equip your site with these tricks and enjoy dual benefit!

Having Helicon Ape installed, open httpd.conf file in Ape installation folder using Helicon Ape Manager. To be able to manage the module you should uncomment corresponding LoadModule directive, as shown on the picture:

IIS possesses its own facilities for GZIP compression. These must be disabled if you are going to use mod_gzip for these purposes. Helicon Ape has a lot more means for more flexible and fine configuring. To disable internal compression in IIS please run IIS Manager, in the tree on the left choose server or specific site. Now open ‘Compression’ element and put the ticks as shown below:


Now we are ready to start writing a simple config. Let’s enable compression for all requests first. According to the docs this may be accomplished in three ways. We’ll use environment variables:

SetEnv gzip

The above line does the following: enables mod_gzip, allows compression for all types of requests, applies default compression level of 6.

Easy, isn’t it? “But where’s the flexibility you promised?” – you wonder. Not all files may be compressed to the same extent. It’s well-known for instance that text documents are more “compressable” than images. And for PNG, JPEG, GIF formats the benefit may tend to zero! And everything would be just great if the module’s operation didn’t take time. So why waste time to fruitlessly compress almost uncompressable files if we can simply say mod_gzip not to touch them. Let’s use mod_setenvif module to disable images compression:

SetEnv gzip
SetEnvIf mime image/.* no-gzip

Much better this time, right? Yeah, better but not the best:) mod_gzip can do even more! Let’s play with compression level now. The default value is 6 but maximum is 9. And sometimes the difference is noticable. As we know the text is compressed well, let’s set it’s compression level to 9, we’ll still ignore images and everything else will be compressed by default:

SetEnv gzip
SetEnvIf mime text/.* gzip=9
SetEnvIf mime image/.* no-gzip

Another situation may be that you want to compress only specific file types. Say you want only HTML/CSS/JS to be compressed with maximum compression level:

SetEnvIf (mime text/.*) and (mime application/x-javascript) gzip=9

Note! If you previously were an Apache fan, the above syntax may surprise you. Yes, it’s true – it’s applicable only in Helicon Ape (for your own good). Here you may find more information on extended syntax.

But if for some reason you want your Helicon Ape config to be compatible with Apache, here the equivalent to what we’ve done before:

mod_gzip_on yes
mod_gzip_compression_level 9
mod_gzip_item_include mime text/.*
mod_gzip_item_include mime application/x-javascript

And the most delicious dish in the end;) We’ve made some kind of compilation of the most effective mod_gzip and mod_cache settings that you may use on your server as is. mod_cache is used to speed up the delivery of compressed content to the user. These two modules working together substantially improve server performance. So here’s the piece that’ll make you happy:

# By file extension
SetEnvIfNoCase request_uri \.mdb$ gzip=9
SetEnvIfNoCase request_uri \.bmp$ gzip cache-enable=mem
SetEnvIfNoCase request_uri \.(?:jpg|gif|png|swf|avi|rm)$ no-gzip                        

# By MIME type
SetEnvIfNoCase mime text/.* gzip=9 cache-enable=mem
SetEnvIfNoCase mime audio/wav gzip cache-enable=mem
SetEnvIfNoCase mime image/bmp gzip cache-enable=mem
SetEnvIfNoCase mime message/rfc822 gzip

SetEnvIfNoCase mime application/msword gzip
SetEnvIfNoCase mime application/postscript gzip
SetEnvIfNoCase mime application/vnd.ms-excel gzip
SetEnvIfNoCase mime application/vnd.ms-powerpoint gzip
SetEnvIfNoCase mime application/vnd.ms-works gzip
SetEnvIfNoCase mime application/x-javascript gzip cache-enable=mem
SetEnvIfNoCase mime application/x-msaccess gzip
SetEnvIfNoCase mime application/pdf gzip

# Exceptions for old browsers
#BrowserMatchNoCase \bOpera(?:\s5\.|/5) and \
#    mime application/.* no-gzip vary-agent !cache-enable
#BrowserMatchNoCase \bMozilla/4\.[67] and \
#    (mime application/.* or mime image/.*) no-gzip vary-agent !cache-enable
#BrowserMatchNoCase \bNetscape(?:6/6\.|/) and \
#    mime application/.* no-gzip vary-agent !cache-enable#BrowserMatchNoCase \bFirefox/1 and \
#    mime application/pdf no-gzip vary-agent !cache-enable

SetEnvIfNoCase (mime text/css) or (mime image/jpeg) vary-agent
BrowserMatchNoCase \bMSIE\s[567]\. and \
    (mime text/css or mime image/jpeg) no-gzip vary-agent !cache-enable

# Vary header should be properly set for cachingHeader merge Vary User-Agent env=vary-agent

# Set expiry delta for static content
# Dynamic pages should set expiry delta by oneself
Header merge Cache-Control max-age=86400 env=cache-enable

You can enable the above preset for your server by uncommenting a single line in httpd.conf:

Include smart_gzip_compression.conf

Conclusion
As you can see, not so many rules are needed to adjust mod_gzip for our needs. We also showed you some examples of Helicon Ape extended syntax, but you may as well use standard Apache-compatible one. We are trying to give you a rich set of instruments, so that you can combine them the way you want and deem necessary. But simplicity and convenience are above all.

Always yours,
HeliconTech Team

Until recently HeliconTech had one specialized solution for content compression – HeliconJet. We have decided to include its functionality to our new product – Helicon Ape , accounting for its importance. So far as Ape stands for APache Emulation, it’s very important not to invent new syntax nd directives but use existing Apache assets.

There are 2 popular compression modules – conventional mod_deflate and mod_gzip. The last one is written by third party developer and is not supplied with Apache. We have decided to implement both modules because users are using them to the equal degree. At the moment only basic
mod_gzip functionality is realized but we are planing to extend it in the nearest future. Technically Ape will have one compression module which will be able to support both mod_gzip and mod_deflate syntaxes. Our primary goal is to give you an ability to easily use existing Apache configuration without any changes.

Let’s have a look at basic content compression principles and mod_gzip operation. This module applies GZIP format which uses Deflate compression algorithm. The module is based on .NET version of the popular library ZLib. Please note, Helicon Ape is written in managed code only!

Web-client (browser) exchanges technical information (so-called HTTP headers) with web-server. These headers contain important information helping client and server get mutual understanding. Client can point to accessible data type and needed content. Taking into account client abilities the server prepares and sends the content. After that technical information helps client understand what to do with the server response.

But we are not gonna dive deep into HTTP protocol subtleties as there are tons of info on this topic in the Internet. Lets recur to mod_gzip . General scheme of its operation is given below:

As you can see not only server takes part in considering whether to compress content or not. It is easy to understand ’cause if browser isn’t capable of uncompressing GZIP, then all mod_gzip operation will be senseless and the user will get rubbish. Web-client must send Accept-Encoding header with gzip, x-gzip or deflate value to let mod_gzip know whether the client supports compression.

In its turn, if the module makes a decision to compress content, it sets Content-Encoding: gzip header to inform the client that GZIP uncompression must be used. So, each chain on the scheme above plays
important role.

But to better understand mod_gzip logic, please have a look at this flowchart:

The sequence is used by mod_gzip to make compress/not compress decision. We’ll now give a brief explanatin of each stage:

• When request comes to the server mod_gzip (if it’s ON) can start its “dirty”
  work.
• Firstly, the module defines whether the content is already compressed. If it is, mod_gzip
  leaves things as is.
• If it’s not, the module analyses request headers sent by the client. mod_gzip
  can move on only if there’s Accept-Encoding header with gzip, x-gzip
  or deflate value.
• On the next step the module performs check set by
  specific directives inside configuration files. Based on results of these
  checks decision about content compressino is made.
• If it’s necessary to use GZIP, the module will SET Content-Encoding: gzip header, ’cause
  otherwise the client may fail to process server response correctly.
• Besides, there’s a special Vary header in which mod_gzip specifies what its actions depend on
  (Vary: Accept-Encoding). This header is used for caching, so it’s detailed description will appear in the
  upcoming articles.

It’s possible that in next versions will have slightly different logic, but we’ll surely inform you about that.

Resume

This article is just a brief introduction to Helicon Ape mod_gzip module.
We are thinking of writing much more material on that and other topics to help you use our little agile monkey (Ape) easily and efficiently.

Best wishes,
HeliconTech Team

Step 1. MySQL

After MySQL installation run MySQL Command Line Client and execute the following command:

create database wordpress;

Step 2. PHP

Install PHP into C:\inetpub\php to inherit NTFS permissions of IIS directory. It is of importance that C:\inetpub\php\php.ini contained the following directives:

magic_quotes_runtime = Off
extension_dir = "C:\inetpub\php\ext\"
extension=php_mysql.dll

After ensuring the directives are in place you need to register PHP in IIS configuration. To accomplish this:

• open IIS Manager
• open Handler Mappings snap-in

  

• press ‘Add Module Mapping’ and fill the fields in the opened window in accordance with the next screenshot (all images are clickable)

  

Step 3. WordPress

Download the latest WordPress version

Unzip the package into C:\inetpub\wwwroot\wordpress

Rename wp-config-sample.php into wp-config.php.

Adjust MySQL connection:

Create a blog

Now in Administrative panel you can set SEO-friendly format for your links, e.g: /%post_id%/%postname%

Your links will now look like http://localhost/wordpress/2008/uncategorized/hello-world

instead of http://localhost/wordpress/?p=123. If you now attempt to access any of the pages on your blog,

you’ll get 404 Not Found error

And that is defenitely not the desired result!

Step 4. Helicon Ape

It’s time to fix the above inconveniences and accelerate WordPress.

We’ll use the following Helicon Ape modules:

4.1 mod_rewrite

It’ll assist us in handling SEO-friendly URLs.

Open Helicon Ape Manager and uncomment/add the following line in httpd.conf to enable mod_rewrite:

LoadModule rewrite_module  modules/mod_rewrite.so

Now in Helicon Ape Manager browse to WordPress folder and put the following code to .htaccess:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) index.php?$1 [L,QSA]

This piece of code checks whether the requested resource is physically located on the disk and if it doesn’t, performs rewriting to index.php.

Save changes to .htaccess. Request any blog page once again… It works!

Yes, it does… but not the best way… So we are moving on! ‘Cause only the best is good enough:)

4.2 mod_expires: client/proxy content expiration

With this module we’ll adjust browser cache so that the browser doesn’t send excess requests to the server. Go back to httpd.conf in Helicon Ape Manager and uncomment/add the following line:

LoadModule expires_module  modules/mod_expires.so

Subsequent lines (being put to .htaccess) will tell browser cache that images, css and JavaScripts must not be requested from the server (but rather taken from cache) within 1 day after retrieving resource for the first time:

ExpiresActive On
ExpiresByType image/jpeg "access plus 1 days"
ExpiresByType image/gif "access plus 1 days"
ExpiresByType text/css   "access plus 1 days"
ExpiresByType application/x-javascript  "access plus 1 days"

Let’s check what’s changed. The first request grabs all page resources and for each image, css and JavaScript sets the header Cache-Control: max-age=86400

Upon consequent requests to that page the browser does not ask for images, css and JavaScripts from the server but takes them from the cache until max-age expires.

4.3 mod_gzip

Are you enjoying the process? Then let’s implement the next stage. To make things even better, let’s apply on-the-fly compression that will reduce traffic and speed up page load. In our irreplaceable Helicon Ape Manager please uncomment/add the following line inside httpd.conf:

LoadModule gzip_module  modules/mod_gzip.so

And put the following lines into .htaccess in WordPress folder:

mod_gzip_on yes
mod_gzip_item_include Mime ^text/.*

These directives instruct Helicon Ape to compress only those resources which type starts with “text/”, i.e. all text, .html and .css files. Usually images and video compression is useless.

Uncompressed page had Content-Length: 5152, the same page after compression became as small as Content-Length: 2168. So, we’ve managed to reduce the amount of info to be transferred almost twice.

4.4 mod_cache

We are coming to the final and in conclusion we’ll enable server-side caching. Instead of requesting the same page from the server again and again Helicon Ape saves the copy of server response and fires with it when corresponding page is needed.

Uncomment/add the following line in httpd.conf (using Helicon Ape Manager):

LoadModule cache_module  modules/mod_cache.so

We’ll only cache index.php page. It will be stored in cache for 30 seconds so that the site looked dynamic. There’s no need to cache static files (.html, .css, images, Flash, videos) because IIS processes them really fast.

Note! It is worth mentioning that cache distinguishes query string parameters, thus it will store different snapshots for different blog pages.

There are some shortcomings of this type of caching (semi-dynamic web application). E.g. if the user posts a comment on the blog, it will see the result (his post) immediately, but another user browsing this page will only see it in 30 seconds (after cache expires). This issue may be resolved by reducing the time snapshot lives in cache, but it should nevertheless be taken into account.

Put the following lines into .htaccess in WordPress folder:

<Files index.php>
ExpiresByType "text/html; charset=UTF-8" A30
CacheEnable mem 
CacheVaryByHeaders Original-Url 
</Files>

Let us compare the productivity with and without cache. On our testing virtual machine we’ve obtained the following values:

• without cache – 7.45 requests per second
• with cache – 711 requests per second!

4.5 mod_headers

The last drop we want to add to our WordPress-based dish will hide IIS from robots and scanners.

You need to uncomment/add the following line in httpd.conf:

LoadModule headers_module  modules/mod_headers.so

And put the only line into .htaccess:

Header set Server "Apache/2.2.9 (Unix)"

Now our IIS appears to the world like

Congratulations to everyone who came to finish! It’s all done now! Enjoy flawless and fast WordPress operation and stay with us!

Best regards,

Helicon Team.