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;

(See ngx_gzip_module documentation for details)

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).

[via www.webscalingblog.com]

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

( Read more )

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!

( Read more )

With a many of webmasters switching to Virtual Private Servers (VPS) from shared hosting and preferring them over costlier fully dedicated servers, the main issue is memory and resource optimization. Most VPS packages have dedicated memory constraints of 128MB to 256MB. Apache and MySQL are known to be the most memory (resource) intensive applications that tend to crash or slow down a low to mid range VPS often. While OpenVZ or Virtuozzo based VPSs can have a memory limit in addition to the dedicated RAM to high memory needs, Xen based VPSs can not use more than the stipulated amount of dedicated RAM, adding to the problem.

In this short do-it-yourself Apache and MySQL optimization guide, I will present some small yet useful tips that I have collected from the net and will also share my own VPS settings and experiences that I hope would be very useful to first time and newbie VPS owners. I would also like to make it clear that I’m not a system admin or server guru of any caliber, but a techie and geek who loves to try and do things himself. So, always make a backup of files concerned and don’t hold me responsible for any kind of loss incurred. Try at your own risk!


( Read more )