Compressing content on server before sending it over HTTP is a good practice since it saves a lot of traffic and makes transfers faster.
For example, Prototype.js is 123KB size and after Gzip compression it becomes only 28KB.
GZIP Compression also affects HTML so even primed cache requests that downloads mostly only HTML will be faster.
So we should enable server-side compression of textual components: Stylesheets, Javascript, HTML, XML (there is no need to compress images as they already compressed).

For Apache2:
compression done by mod_deflate

AddOutputFilterByType DEFLATE text/html text/plain text/css text/javascript application/x-javascript text/xml

For Lighttpd:
enable mod_compress in lighttpd.conf and add configuration directives:

compress.cache-dir = "/tmp/"
compress.filetype = ("text/plain", "text/html", "application/x-javascript", "text/css", "text/javascript", "text/xml")

Nginx configuration directives:

gzip on;
gzip_min_length 1000;
gzip_types text/html text/plain text/css text/javascript application/x-javascript text/xml;

Besides compression there is minification (removing comments and unnecessary whitespaces) that can further reduce size of Javascript.
Minified Prototype.js becomes 92KB size uncompressed and 23KB compressed, this is 20% less than compressed non-minified script.
There are number of tools for minification exists, I’m using JSMin (http://crockford.com/javascript/jsmin).

Caching speeds up repeated page views and saves a lot of traffic by preventing downloading of unc hanged content every page view.
We can use Cache-Control: max-age=… to inform browser that the component won’t be changed for defined period. This way we avoid unneeded further requests if browser already has the component in its cache and therefore primed-cache page views will be performed faster.
Modern browsers able to cache static files even without any cache control headers using some heuristic methods but they will do it more efficient if we define caching headers implicitly.

For Apache2 you can enable max-age using mod_expires:

ExpiresActive On
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType text/css "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
ExpiresByType application/x-javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"

For Lighttpd there is mod_expire module. Enable it in server.modules section:

server.modules = (
...
"mod_expire",
...
)
Then add following directives for directories with static files:
$HTTP["url"] =~ "^/images/" {
expire.url = ( "" => "access 30 days" )
}

Max-age for Nginx server can be enabled using ngx_http_headers_module:

expires max;

Now web server sends the caching header for static files:

Cache-Control: max-age=2592000

In case of design change we should prevent using outdated content that browsers have in their caches. This can be done by adding file versions to filenames:

script.js -> script1.js -> script2.js -> ... etc

What if we cannot predict lifetime of page content? If we have a page with info that changes unpredictably we still can use browser cache to avoid unneeded traffic.
Using validation mechanism browser sends HTTP request with info about cache entry and server can respond that the content wasn’t changed.
There are two validation methods: one is based on Last-Modified and the other is based on Etag.

Last-Modified
Server sends Last-Modified header with datetime value that means the time when content was changed last time.

Cache-Control: must-revalidate
Last-Modified: 15 Sep 2008 17:43:00 GMT

The first header Cache-Control: must-revalidate means that browser must send validation request every time even if there is already cache entry exists for this object.
Browser receives the content and stores it in the cache along with the last modified value.
Next time browser will send additional header:

If-Modified-Since: 15 Sep 2008 17:43:00 GMT

This header means that browser has cache entry that was last changed 17:43.
Then server will compare the time with last modified time of actual content and if it was changed server will send the whole updated object along with new Last-Modified value.

If there were no changes since the previous request then there will be short empty-body answer:

HTTP/1.x 304 Not Modified

And browser will use the cached content.

What is one of the most challenging issues for bloggers who want good standpoint from search engine? It’s canonicalization, a process of converting the data with more than one representation into the canonical standard. Bloggers concern very much with this issue this process that will define the duplicate content of blogs or otherwise through the so-called algorithms work to sort the data repetition in order. Yet, this hot issue has been tactically responded through the redirecting the blogs from www to non-www or conversely.

In fact, the URL canonicalization is a long topic of discussion where people in common make a mistake to understand about. URL canonicalization is believed unable to go beyond www and non-www. Yet, the know-how basics are still out of the track. Let’s discuss this topic to get a precise insight on URL canonicalization in relation to an effort of redirecting www to non-www or vice versa.

A problem of 301 Permanent Redirect plugins

We normally find within the plugin directories of WordPress similar utility for redirecting www with 301permanent redirect. Actually, most of these plugins are not helping much to make URL canonicalization effects come away from our blogs, since one version include the functionality of Apache-based redirection, 404 monitoring, and many more. I do not need to mention the names of other remaining plugins due to the fact that they are superfluous. Furthermore, some of these redirecting options could distract the performance of your WordPress blogs.

The case is basically not the simplicity of the redirection tools available in the plugins. Using such plugin to remove the meta data header tags from the given standardized WordPress header doesn’t allow modifying the codes that have been set up. If only it is possible, we can simply upgrade and that will serve what we want from redirecting effort.

Here you a typical WordPres redirection taking the following process.

Web browser → Web server → WordPress(PHP) → MySQL

Since the data is within MySQL database, we need to through these steps and thereby every adds could delay the on-the-way process. The opposite redirection steps will be simply otherwise where the delay occurs in every single step.

When the web server is already optimised, it will neglect the necessity of using PHP to process static files and others. It means that you have already added your CPU and server with unnecessary memory usages. As a result, the effects of redirection are not only delayed-time use, but also the basic principle of performance wisdom itself. In short, we have to stay away from using the WordPress core plugins to redirect www to non-www and conversely. No way!