After several posts about data:URI and actual data:URI performance impact let’s see how this technique can affect website performance or some other sides of website consistency or website speedup issues.

Large resource file size

It’s the main reason why data:URI + mhtml is used so rarely. Webmasters are afraid of large final file size – and just do not include background images in base64 format. There was discussed some ways to prevent large assets of data to be loaded before the content is whon in browser in one of the previous articles – even faster styles. This approach allows you to delay actual load of resource CSS file, so it won’t influence much your website load time.

Also here you can very thoroughly clean up styles or create CSS Sprites. Both this ways can help you to reduce drwabacks from large data:URI chunks of data.

Cross browser compatibility

data:URI can be used only for IE8 and all modern browsers. For IE7- you need to use either raw background images or mhtml approach. The last one leaks under IE7@Vista, but can be fixed with this approach (which is already included into duris.ru or WEBO Site SpeedUp).

The whole technology is a bit complicated (you need to restrict data:URI images’ size and properly use mhtml to get the best results). But can be integrated for any website.

Security issues

The main issue here is related to Firefox. It took 3.5 years to fix it, but now the main issue with data:URI on SSL-protected websites usage is fixed. The other browsers don’t have known issues here.

Also there are possible vulnerabilities in data:URI / mhtml parsing (buffer overflow, etc), which must be fixed in browsers before you can completely safely use base64 to present data in your web projects.

Also one of the possible solutions is to include data:URI chunks inside the HTML page, so all data will be encoded properly.

Performance issues

data:URI takes much more time to be processed (in comparison to CSS Sprites or raw images) – about 10x more (for Firefox, for IE – 2x, for Opera/WebKit almost the same time). So in case of large images’ square (starting from 400×400, or 100k square dots), so you must be careful ibefore you completely convert all graphics to base64.

Before browsers can parse data:URI completely efficiently you can balance graphics between data:URI (+mhtml) and CSS Sprites, so the total performance will be still very high.

Conclusion

You can combine background images to data:URI view, but you should know about all drwabacks which can be caused with this performance optimization technique. And all solutions which can be used to prevent them.

Related Posts

• January 23, 2010 -- CSS Sprites: revealing sealed mystery (1)
• February 11, 2010 -- Hacking timthumb.php – all the best practices (3)
• January 19, 2010 -- Too many styles? Shrink them! (1)
• March 3, 2010 -- JavaScript Combine and Minify – troubles and solutions (0)

In the prvious posts we stated that dynamic images are bad and how images (from timthumb) can be statified. Let’s speak today about dynamic CSS / JavaScript files and see what can be done here.

What is dynamic CSS / JavaScript files?

All style sheets and JavaScript calls which has extension not .css or .js (but .php). As an example you an take a look at gdsr.css.php file (which is a part of GD Star Rating plugin) – this one is beter than a common example because it allows client side caching.

So all PHP-based CSS / JavaScript files are dynamic and thus evil. Let’s see why.

Reason 1. PHP execution is expensive

Each ms is valualbe for your website. And dynamic file’ generation costs about 2-3x more expensive that plain (=static) files. This is not very important in comparison to WordPress (or any other CMS) execution time to generate HTML document. But while using strong caching techniques (and creating high performance websites) such costs become valuable.

Reason 2. PHP files are not cached

Usually (note: sometimes it’s not true) dynamic PHP files don’t set proper client side caching headers (both far future and conditional ones). This is very bad because with every page request takes additional time from server to generate this file and additional time from client browser to load it. There is double drawback here.

Reason 3. PHP files has GET parameters

The main reason why sometimes PHP scripts are used to serve CSS or JavaScript content is a feedom to server different content for different initial (GET) parameters. This is very convenient for developers but is not so good for client side performance – because some proxy servers don’t cache files with GET parameters in URL (because they can be dynamic), and this leads to slower website load.

Reason 4. PHP scripts are buggy

Classical example here is Featured Content Gallery which sends CSS files with wrong Content-Type (under certaion conditions). This breaks layout is modern browsers.

Static files (especially on VDS / shared hostings) serving is being tested for years. And all related issues (i.e. Content-Type) were closed long time ago.

Reason 5. PHP scripts are not gzipped

It’s very easy to add gzip to static files (i.e. with static gzip). But if you are going to gzip every dynamic PHP script – you need to alter it manually. And do it with every plugin update (or ask repeatedly authors to add fix for gzip).

Gzip for CSS / JavaScript files can save about 80%, so it’s a huge drawback.

Reason 6. PHP scripts are hardly combined

THe most famous tool – WP-Minify – to combine static CSS / JavaScript files fails on dynamic (PHP) ones. Because they must be executed first and only then merged with the rest content. So there must be applied more advanced merging techniques or you will have to disable textual files merging at all.

Reason 7. PHP files are not minified

Yes, there can be any type of minify applied to the content of PHP files. But it’s implemented very rarely (and almost never right). For example there is no place for comments (client side) in such dynamic files – all they can be left in PHP code.

Reason 8. Inline code isn’t included

It’s a very simple idea – as far as we have dynamic file why do we need to include any piece of additional code into HTML document? We can serve all related chunks of data inside the only dynamic file (due to PHP flexibility) – but actually each plugin includes 2-3 files + a few chunks of data.

There can be some more arguments why developers must think more about performance. And prefer static files (or pre-generated ones) instead of dynamic PHP scripts to serve CSS / JavaScript content. But let’s see how can we fixe this.

Solutions

There can be the only ‘true’ way to avoid such dynamic scripts on your website – just merge them together (or convert) into static files. This is quite painfully but with automated solutions can be like a dream. After this you can simply apply gzip or client side caching.

We reviewed some WordPress plugins to merge scripts and here is the only clear winner – WEBO Site SpeedUp (you can check also performance comparison table). So there are only two ways: to perform all actions manually (to improve your website performance) or prefer an automatic solution. It seems there is no chance to stop using plugins with such dynamic content (or force all authors to use performance optimization best practices).

Conclusion

PHP scripts (for CSS / JavaScript content) have many negative features. So you need to use them or… to fix them manually or automatically.

Related Posts

• February 26, 2010 -- All about WordPress performance – 11 golden rules (1)
• January 20, 2010 -- data:URI is the next generation of acceleration techniques (2)
• January 19, 2010 -- Too many styles? Shrink them! (1)
• January 17, 2010 -- Less files – faster website, but how much? (2)

We minified and combined all JavaScript files on our website and got about 250ms gain in load speed (or 6%) and website performance. It’s not so much but JavaScript minify technique can be very dangerous in few cases. Let’s speak how to reduce number of failures with scripts merging (manual r automatic).

Minify tools

Some troubles are related to improper minify tool selection. There are a few well known tools, let’s review them.

• JSMin (or JSMin+). The first one is very fast and powerful (minify up to 5% over initial gzip). The second one is CPU expensive, but can gives you more minify (it seems about 6-7% over gzipped version). But both tools can be used for sure in any case (due to some reasons of finite states automation – some JavaScript constructions and variable scopes can’t be shrinked for sure), and there are some errors (very rarely fortunately).
• YUI Compressor. More robust tool which requires java. Most of hosting environment (PHP-based) don’t have it (or don’t allow to execute shell scripts to envelope java calls). The second drawback is that YUI Compressor (due to java virtual machine usage) is very heavy (about 10x more CPU expensive than JSMin). And it give about 6-7% additional compression (with gzip).
• Packer (from Dean Edwards). It can be very useful if you can’t apply gzip for JavaScript files because it creates some kind of archive with JavaScript itself. This adds payload every time with script initialization (with every page) but in case of small libraries can be helpful. This method also often breaks initial JavaScript code (due to not standard-complaint assets). Be careful.
• Google Compiler. Very powerful tool (and can save about 10-20% more over YUI Compressor, so up to 10% over gzipped JavaScript file) but is hard to use (a lot of options) and also required java on the server. So it’s better to use it on a local PC or in production schema.

Also you can write your own tool to reduce your scripts (maybe be even faster and more efficiently than all mentioned ones) but you should test all functionality after each such minify action.

Combine troubles

The most of WordPress websites has about 5-10 JavaScript files per page. Plus some inline code (which activates such libraries). Finally about 10-15 chunks of JavaScript code. Each of these chunks can be broken (due to bad plugin compatibility, old or non supported browser, or for any other reason). So if we just merge all chunks together we can get completely broken client side logic what is caused by the only JavaScript error (with an old plugin, or conflicts between plugins).

So we can’t combine JavaScript files for sure at all?

Actually, no, we can’t. But there are few approaches to inject graceful degradation to JavaScript combine logic.

Graceful degradation and back compatibility

First of all we can merge together only JavaScript libraries themselves. Without inline code. This can guarantee (in the most of cases – because usually there are used generic libraries which have great compatibility) more or less stable work in almost all cases.

But there is one drawback – we can’t place for sure merged file before all inline calls or after them. Because some libraries (in this merged package) can be used for further logic. And some can be called with parameters (which are defined a bit earlier), and such parameters must be followed by JavaScript libraries. So we need to have an option – where to place merged JavaScript file. And WEBO Site SpeedUp has it.

The main approach here is to envelope each JavaScript chunk into try-catch construction. So we can execute all code in combined file and it the case of any failures just inject into the document initial JavaScript call. Final code will be the following

try {
	... content of JavaScript library ...
} catch (e) {
	document.write('initial JavaScript file call');
}

Our combined file (with such constructions) won’t be loaded ‘on fly’ (so document.write won’t break anything), and try-catch logic will provide required compatibility.

The only drawback here is that try-catch construction ‘eats’ CPU. And these expenses will occur on every page load. But this provides a safe way to combine any JavaScript together (of course without any troubles with code order which can be solved only as described above).

Conclusion

There are several reefs in JavaScript combine and minify – minify tools has different features and server side support. Also minified code must be tested after minify. Additionally you should use safe combine approach to be sure that all included JavaScript libraries are being loaded and don’t conflict with each other.

Related Posts

• February 23, 2010 -- 5 quick tweaks for WordPress performance (1)
• January 14, 2010 -- Caching everything, caching everywhere (1)
• February 2, 2010 -- HTML minify – to be or not to be? (4)
• March 26, 2010 -- data:URI + mhtml troubles and solutions (0)

Let’s review our achievements for a WordPress-based website and create something like a road map to optimize WordPress performance.

First priority actions

• Gzip of die! You must gzip all appropriate files (i.e. HTML, CSS, JavaScript, ICO and Fonts). You can use here ‘on fly’ gzip approach (via .htaccess or PHP), then continue with static gzip technique, and review some external (and maybe useful) ways to apply gzip for your website. Here you can save about 20-50% of website size (it depends on how much images do you have, for this website it was 25%).
• Shrink your images. You should review and integrate any of image optimization strategy into your blog. Or use some advanced optimization tools. Anyway you can save about 30-40% of website size here (34% for this website).
• Cache everything. You can use both client side caching (even with disabled server-side support for it) and server side caching (latter eliminates a huge pack of performance issues with your website – so just apply it and forget about troubles). These techniques are pretty simple to integrate into the website and cut your traffic and save your visitors’ time. Also this increases your website capacity (just by removing server side expenses). And it’s about 10-20% speedup for new visitors.

After these 3 steps you will have 2-3x accelerated website. And all this can be applied with a few of actions (there is a lot of software to implement this automatically).

Second-priority actions

If you think your website isn’t fast enough after the previous actions you can case some more client side magic. It’s more complicated and give you less performance, but is still worth to be implemented.

• Combine CSS and JavaScript files and minify them. Gzip saved you a lot of traffic but you can save more and reduce number of HTTP requests here. Depending on your website complexity this can give your 10-20% speedup.
• Review applying data:URI or CSS Sprites technique. To increase efficiency for these techniques you can delay data:URI resource file load or convert HTML images to CSS images. Actual result here is about additional 20-40% speedup.
• Use multiple (mirroring) domains or even CDN. Actual speedup here greatly depends on how you have applied the previous steps. If all was done right – it’s about 5-10%. If you can apply some of the previous steps – speedup will be greater, about 20-50%.
• Use static images instead of dynamic ones. This will reduce server side load.

All mentioned steps are not very hard to implement for your website but can give you up to 1.5x additional speedup. So the total website performance improvement will be 3-4.5x.

Third-priority steps

If you are still not sure about your website high performance (yes, even after 4.5x speedup this can be possible). You can think about the following actions.

• Remove unused styles. Be careful with CSS – it can be used on rare internal pages. Actual performance gain here is 2-5%.
• Use HTML minify. This will make your website much faster for returned visitors (as far as they have all static resources cached). And add about 0.5-1% to website load speed.
• Remove blocking advertisement blocks. You can use simple delayed load for any ad blocks (i.e. AdSense). This will increase website rendering speed.
• Use HTML Sprites. After applied CSS Sprites and multiple hosts this technique won’t give much. Maybe additional 2-5% to website load speed.

We don’t touch cookie-free domains and website rendering optimization because in most of cases they give you nothing.

Conclusion

You can easily get 3.5-5x+ website acceleration if you implement all these rules. But more than half of actual performance you will get after first 3 simple steps – gzip, image optimization, and caching.

Related Posts

• January 29, 2010 -- Reviewing speedup – from advanced to extreme website acceleration (0)
• January 16, 2010 -- Reviewing speedup – from basics to advanced techniques (1)
• March 7, 2010 -- Dynamic CSS / JavaScript files are evil – 8 reasons (4)
• February 21, 2010 -- HTML Sprites – new weapon against HTTP requests (2)

After we accelerated our website 3x, 5x, and even 40x let’s implement some quick tips to add more performance. Actual improvement is hard to measure, but all these tweaks should add not client side performance but reduce server side load (and improve website usability).

Add favicon.ico to the website root

It can be unclear – why should we use favicon.ico at all, and why should we duplicate it in the root of the website. But most of browsers request not only favicon (website icon) as it’s defined in HTML code (and located for example in our theme folder) but also the root icon. And if there is no such file website serves 404 page which is larger, and it takes much more time to serve it than a static favicon.ico.

Please just place favicon.ico to the website root.

Add static 404 page

WordPress has powerful SEO friendly URLs rewriting logic. But it leads to serve all requests via WordPress core (except static ones). This is provided by the following rules in .htaccess file

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Every not cached request to your website can be painful. And if you don’t cache 404 errors (why you should cache them?) – HTTP requests to not existent resources can put down your website – but provide no valid visitors.

To create additional template for 404 page – just put file 404.php with proper code (you can copy index.php from this folder and add some changes). In our case the final file is wp-content/themes/basicpress/404.php. You can also add some ‘404 not found’ snippets to provide better usability (i.e. a Google 404 widget). Final output will look like the following one.

Please add 404 page to your website (maybe even a custom one).

Redirect RSS feed

If you are using FeedBurner to collect your readers – just rewrite all requests there. Why it’s important? Because if you have hundreds of readers requests to RSS feed on your website will add server side load. And this can be easily eliminated by redirecting all such traffic to FeedBurner which uses its own capacity to manage all RSS requests.

Just add to .htaccess (before mentioned rules above – before generic redirect to index.php) – to perform this .

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} !FeedBurner    [NC]
RewriteCond %{HTTP_USER_AGENT} !FeedValidator [NC]
RewriteRule ^feed/?([_0-9a-z-]+)?/?$ http://feeds.feedburner.com/SpeedingUpWebsite [R=302,NC,L]
</IfModule>

Here you should replace SpeedingUpWebsite with your RSS id on FeedBurner. If you are using another aggregator – just redirect your users on it.

Please redirect all RSS requests to RSS aggregators.

Prevent hotlinks to images

We can also restrict placing your images on the other websites than the initial one. This will save number of HTTP requests for your server and reduce your traffic (also this can somehow protect your copyright). To implement this technique add the following rules to .htaccess (also before the last chunk of initial WordPress rules – with index.php).

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?speedingupwebsite.com/.*$ [NC]
RewriteRule \.(gif|jpg|png|ico|bmp)$ - [F]
</IfModule>

Please prevent bandwidth theft.

Create static robots.txt

WordPress also handles requests from search engines to robots.txt file. This won’t hurt your performance much if you leave this file dynamic. But if you looking for extreme performance (or you aware about CPU expenses) – create a static file identical to current dynamic one.

robots.txt file is always located in the website root – so just copy content and paste to a new file.

Please create static robots.txt file.

Conclusion

All such performance hacks won’t increase your website performance significantly but just make you sure that you manage all its possible weak points.

Related Posts

• February 26, 2010 -- All about WordPress performance – 11 golden rules (1)

It’s a bonus post after our we finished our WordPress optimization Stage 3. We faced troubles with a large amount of HTML images (about 20 for the home page) – and don’t have efficient solution to resolve this issue (yes, multiple hosts can fit, but every HTTP request costs for server side about 12-20 ms – the same value as for cached HTML page).

The solution

As you can remember we tried cSprites to fix this issue. But it wasn’t able to create anything on our shared hosting with very limited resources (also there is no option to exclude images or restrict them by dimensions).

But there was added support for HTML Sprites in nightly builds of WEBO Site SpeedUp. And it works (for this website for sure) with limited memory and doesn’t need a lot of CPU. And we are lucky to have this amazing web performance solution.

Moreover the modern browsers (IE8 + all alternative ones) support data:URI technique, so we can insert our 1×1 transparent GIF file as a base64-encoded chunk of data. With gzip over HTML this reduce total number of HTTP requests by 1 and even HTML document size a bit.

Results

Let’s review what was changed with our website. Before applying HTML Sprtes we have the following chart.

And after them the following one.

We saved 9 HTTP requests but increased overall page size by 330 Kb. Not good – but it’s due to the only Sprite image for the whole website. And this should be configurable (also this can restricted by a list of excluded images). But even without this option progress looks very good – and algorithm is pretty powerful and fast. Final image is 4910×163, and 16 Mb of available memory (we have 32 here, but ~16 can be used by WordPress / WEBO Site SpeedUp core libraries) was enough to create it.

Also right now WEBO Site SpeeUp doesn’t work with dynamic images, but the core handles other dynamic resources well. So it seems it’s a question of 1-2 weeks – and dynamic images (i.e. created via thumb.php) will be added to this functionality.

Conclusion

With HTML Sprites (actually CSS Sprites applied to HTML images) we can save about 20-30% requests. In our case it’s 25%, and the same value for server side expenses – because we have all resources cached. So right now our website can handle 25% more traffic.

Related Posts

• January 23, 2010 -- CSS Sprites: revealing sealed mystery (1)
• January 21, 2010 -- Add more caching with (background) images (0)
• February 26, 2010 -- All about WordPress performance – 11 golden rules (1)
• January 29, 2010 -- Reviewing speedup – from advanced to extreme website acceleration (0)

Well. It’s the last post from our website performance optimization Stage 3. Now we can say for sure – it’s a fast WordPress blog! But what actual gain have we achieved with all these actions? Let’s review them.

Extreme performance actions

• We reduced size of CSS rules. Due to data:URI technique usage this saved us about 75 Kb, or 20% of website size. But it’s an uncommon result – usually this step provides nothing in terms of web performance.
• HTML minify saved for us about 0.6 Kb for every page (0.15% of not cached website size, and about 11% for returned visitors).
• Cookie-free domains. About 10 ms, or nothing (after multiple hosts usage).
• Static HTTP images reduced website load time by about 52 ms (but were not able to efficiently combine HTML images, this seems to be a useful technique after CSS Sprites), or 1% of website load speed.
• Then we saved another 100-200 ms with removing transparent fixed block. This relates to page rendering, not actual network load.
• Finally we delayed all AdSense blocks and got about 150 ms (3×50 ms) with not blocking JavaScript. But all this in case if you have any dynamic ads on your blog.

So simple sum shows about 30% speedup (not 40x, not 5x, not even 2x – only 1.3x). And almost all of this came from removal of unused data:URI chunks. Usually all actions together will give about 10% speedup. It’s very little.

Overall results

These results can be also confirmed with YSlow. Please compare this image (it was taken at the beginning of Stage 3)

with this one (the last YSlow chart).

There is actually no difference. The same number of files (we added a few AdSense – so the latter situation is even worse). But performance didn’t change significantly. We just tuned our website to handle more advertisement with the same initial speed. There is nothing more.

Conclusion

There is no valid reason to integrate to your website extreme performance best practices. You can just apply some basics and advanced techniques, and stop with this. But if you have heavy blog with a lot of ads – unobtrusive JavaScript or unused styles removal should help. This conclusion is proven by numerous graphics and tests, so it’s just your choice – to waste time for nothing or not

Related Posts

• February 17, 2010 -- Removing blocking AdSense (7)
• January 8, 2010 -- The right way to speed up your blog (3)
• January 7, 2010 -- Is my WordPress blog fast enough? (part 2) (4)

It’s the last part of our Stage 3 optimization research. And we are going to perform some actions to remove blocking behavior of AdSense blocks (and any other advertisement as well).

What is blocking JavaScript

Here is a very good article from Steve Souders about how JavaScript blocks web page rendering and how this can be prevented. For our website such blocking behavior can be illustrated the following way:

As you can see here AdSense (googleads.g.doubleclick.net) prevents our pictures to be downloaded (and actually stops page rendering).

How to prevent it

We can just move all our JavaScript libraries to the very bottom of the page (all — counters, jQuery, MooTools, etc, etc). And browser will load them only after the other content of the page will be rendered. Generally it’s good only if you have some libraries which don’t perform document.write code. And what is case of Google AdSense?

Almost every dynamic advertisement network (this can be rich media ones, and context ads, and so on) uses document.write to inject a part of DOM tree (it can be also an iframe) directly to advertisement placeholder. In case of iframes this can be tolerably – because they download all resources in parallel. But browser every time stops to get the initial JavaScript file, and page ‘freezes’ for a while. What is not good.

And how can we handle such dynamic ads?

Dynamic ads — dynamic unblocking

First of all we definitely can load ads in the bottom of the page. But we have a trouble here — we need to move them to initial placeholders. So we can use a piece of JavaScript code to perform this (actually we are just removing blocking behavior, not building a complex system to load all dynamic assets on the web page in a special order).

For example for AdSense we have the following JavaScript code:

<script type="text/javascript"><!--
google_ad_client = "pub-xxxxx";
google_ad_slot = "xxxxxxx";
google_ad_width = 468;
google_ad_height = 60;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>

We need to use here a placeholder with the same height (to prevent content jumping when we inject actual advertisement back). As far as we have here height of 60 pixels we can use

<div id="placeholder" style="height:60px"></div>

And in the end of our HTML document (just in footer) we should write the following:

<div id="sourcecode"><script type="text/javascript">... google code here...
</script></div>

<script type="text/javascript">(function() {
var a=document.getElementById("sourcecode"),
b=document.getElementById("placeholder").parentNode;
b.innerHTML=b.innerHTML.replace(/
<\/div>/i,a.innerHTML);
a.parentNode.removeChild(a)
}())</script>

The first part of this code just consists of AdSense code (which is listed above) enveloped by a container. The second part is a dynamic replacement our placeholder (with a given height) with our advertisement. If you have several different ads — you just need to use different pairs of sourcecode/placeholder for them. That’s all.

Automation and actual results

There is the only WordPress plugin which implements the above logic — it’s WEBO Site SpeedUp. It has about 40 default patterns for known ads and counters.

Actual result from this magic is non-blocking JavaScript. The figure below shows our website load waterfall. As you can see some advertisements are loaded even after onDOMready event (blue line here) is fired.

Conclusion

Depending on ads number and their placement you can significantly improve your website usability and prevent content rendering blocking with AdSense (and any other advertisement) delayed loading.

Related Posts

• February 19, 2010 -- Best practices performance – does it matter? (0)
• January 17, 2010 -- Less files – faster website, but how much? (2)

With this small post we are going to review actual performance of using transparent blocks on your website. As you remember we installed a small WordPress plugin to track MySQL / server side generation time of every HTML page. It’s fixed to the right top corner and has a bit transparent background (opacity: 0.8). For IE it degrades gracefully to position: absolute (it seems without transparency). So for this browser all is OK.

What is wrong with the modern browsers (Firefox, Opera, Safari, Chrome) here?

Actual performance of transparent + fixed

To trace rendering performance (yes, we have never covered this in the previous topics, but it seems for now it has almost the same value as HTTP performance – number of requests and amount of data) we need some tools. We are not going to review them now (you can check this good post from Stoyan Stefanov about rendering tracing). As far as we are going to analyze modern browsers – we need Speed Tracer for Chrome.

Let’s run it and record web performance through scrolling the home (or any other) page of our website.

As you can see we have dozens of rendering events each takes about 80 ms, and this completely load our CPU capacity. So website looks like ’sluggish’ (but there are all resources loaded at that moment).

Removing performance bottleneck

Lucky we – we know what is slow here – combination of transparent and fixed CSS rules for stats block. If you are going to understand what’s wrong with your website – you maybe need to completely debug all mark-up. It can take a lot of time.

So let’s remove position: fixed (just replace it with position: absolute) for this widget. We will have the following graphics.

Wow! Our CPU load has eliminated. And now web pages are being rendered very quickly.

Conclusion

If you are going to use combination of position: fixed and opacity – don’t do this. it breaks any fast website and will waste CPU of your users. Also please be careful with position: fixed itself – as far as browsers have to re-render it with each scrolling (and it can be hardly cached as pre-rendered picture), it will be very costly.

Related Posts

• January 27, 2010 -- Parallelize images – multiple domains in action (0)
• January 16, 2010 -- Reviewing speedup – from basics to advanced techniques (1)
• January 12, 2010 -- Amazing speedup with image optimization (2)
• January 8, 2010 -- The right way to speed up your blog (3)

We discussed in some previous posts what WordPress performance optimization can be achieved from simple hacks in timthumb.php library (or just thumb.php – it depends on current WordPress theme). Let’s bring them all together and review once more.

What is a timthumb.php library?

timthumb.php is a small open source library which is aimed to provide resized copies of given images. It handles several formats (PGN, GIF, JPEG) and can be configured via 4 parameters – width, height, zoom crop, quality. It’s very useful and simple enough. But sometimes it causes severe web performance issues.

This library usually is located somewhere in you theme folder (directly inside it or maybe inside libraries subfolder).

Enable cache

While we were playing with images’ optimization we found that there can be no cache enabled in timthumb.php. So please check around line 45 – there must be

check_cache....

uncommented (without # or // in the beginning of this line). If it’s commented – remove comment. This reduces server side load with every image about 5 times (i.e. from 100ms to 20ms).

Change cache folder

Usually cache folder for timthumb.php isn’t writable. It’s better (also due to the following points) to re-assign cache folder to uploads where all images from blog posts are located. To perform this please

1. Calculate depth level of timthumb.php library. I.e. it’s located inside /wp-content/themes/basicpress/ folder – depth level is 3, in case of /wp-content/themes/basicpress/common/libs/ – 5.
2. Change cache_folder to proper number of repeating ../ + uploads/. Number of ../ must be equal depth level – 1. For eample in case of /wp-content/themes/basicpress/ cache_folder must be equal to ../../uploads/.

Of course you can just set correct (maybe even 0777) rights for default cache directory to make caching working.

Set maximum compression

Last parameter in PNG transformation is actually not quality but compression level. So we can re-define it to get minimum default images’ size. Please find near the line 174

$quality = floor($quality * 0.09);

and as the next string just add

$quality = 9;

This will turn maximum compression for resized PNG images ON.

Set client side caching

According to the post about client side caching let’s find approximately a line 317 (with header Cache-Control) and set it to

header("Cache-Control: max-age=315360000,public");

Then for the next line (maybe 318, with Expires header) increase cache timeout to 315360000:

header("Expires: " . gmdate("D, d M Y H:i:s", time() + 315360000) . "GMT");

Set static redirects

Yes, it was the post about changing our dynamic nature of images to a static one. There are a lot of actions, but this can significantly decrease server side load for your blog (after HTML caching applied).

Eliminate dynamic images

And the last part is how to eliminate dynamic images from you blog (maybe not completely, but a major part of them). We need to set proper dimensions in our WordPress settings

And then just replace dynamic images’ calls in the source code to the static ones. Please check the complete manual.

Conclusion

timthumb.php library can be a performance disaster for your WordPress website. But it can be highly tuned and optimized so overall side effect will be very small.

Related Posts

• February 5, 2010 -- Fighting HTTP requests – combine images (0)
• January 14, 2010 -- Caching everything, caching everywhere (1)
• March 7, 2010 -- Dynamic CSS / JavaScript files are evil – 8 reasons (4)
• February 26, 2010 -- All about WordPress performance – 11 golden rules (1)

Just to remember: it’s our optimization journey Stage 3. And we are trying to extremely reduce amount of data / number of HTTP requests. We have already tried to remove unused styles, minify HTML, and use cookie-free domains. And saved about 75 Kb of data (mainly from styles).

Analyzing HTTP requests

We totally have 25 HTTP requests (only 23 are to our website, 1 is Google Analytics library + 1 is Google Analytics counter).

It’s too much. But we can’t just move 50+ Kb of CSS and JavaScript code to each HTML document – it’s better to leave them separated to improve caching. We lose 2 HTTP requests but gain 50 Kb with every returned page view.

We can also do actually nothing with CSS images – they are too big to be included anywhere. Maybe combine them into 1 CSS Sprite? But it seems our hosting memory restriction (32 Mb only) won’t allow us to perform this.

We can do nothing with favicon. Yes, we can include it into HTML (as base64-encoded data). But most of browsers will still request the root favicon.ico file (just to be sure there is a website icon). And we can’t do anything here. We have already gzipped it (with static gzip) – and that’s enough.

Also we can’t eliminate a request to HTML document. Yes. Really.

Handling images

Why HTTP requests are bad? They are bad not only due to client side performance but also with server side expenses. We use cheap shared hosting and static files take about 12 ms from server to be loaded. Not good because 23*12 = 276 ms. And we can handle only 4 new visitors a second to our website (but about 10-20 returned or continued posts reading visitors). And we need to somehow improve this number.

OK. Simple answer is – use HTML Sprites / Image Maps. But we tried cSprites (it seems it’s the only automated solution for WordPress) – it can’t deal properly with our memory limit. Also we can’t configure it flexibly enough (to exclude some images- not their types, – and to restrict images size, and so on).

Well. No way? Hmm. It seems we need to invent some solution. Because we have 10 posts images for the home page + 3 slide images — all of them can be merged together once a day (yes, we have 1 blog post a day). Total square of these images is

158 * 158 * 10 + 48 * 48 * 3 = 256552 square pixels

GD library (PHP extension to handle image processing) uses about 10 bytes per pixel (not more, maybe less). It’s about 2.5 Mb of memory – to perform HTML Sprite creation with these 13 images. Wow! We definitely need to develop a plugin or any other tool.

Static images

But before we start with such tool let’s make images on our website a bit more static. Actually we have 2 different pair sizes for thumbnails – 158×158 (used in posts’ list) and 48×48 (in slide show) – but we can affect automatic creation of only one of them. Let it be the largest one – 158×158. So we can simply to go Settings -> Media in our WordPress admin interface and set proper thumbnails sizes there.

Note: before the next step please don’t forget to prepare -158x158 files for your blog posts – just because changes in Media don’t affect already created images. If you already have static images from timthumb library – you should simply copy -158-158-1-80 ones to -158x158.

Well. Here we are going to change our templates (it’s BasicPress theme). You need to touch files index.php, and archive.php. We are replacing call to timthumb with proper static image. So lets’ remove this chunks of data:

<?php bloginfo( 'template_directory' ); ?>/timthumb.php?src=

and

&w=158&h=158&zc=1

(the last one can contain different dimensions, i.e. w=158&h=158 and quality parameter after zc, but you should remove all this request string).

So for images you will have something like the following

<img src="<?php echo get_post_meta( $post->ID, "image_value", true ); ...

Here we need to change this raw image with minified one (not to send to visitors huge scaled images).

<img src="<?php echo preg_replace("/.png$/i", "", get_post_meta( $post->ID, "image_value", true )); ?>-158x158.png ...

Please note: we also added -158x158.png to this value (and removed .png from its end). If you used JPEG images with PNG – you should alter this a bit.

So initial piece of code

<?php bloginfo( 'template_directory' ); ?>/timthumb.php?src=<?php echo get_post_meta( $post->ID, "image_value", true ); ?>&amp;w=158&amp;h=158&amp;zc=1

is transformed to

<?php echo preg_replace("/.png$/i", "", get_post_meta( $post->ID, "image_value", true )); ?>-158x158.png

And this is applied to all images with required dimensions.

Please do not touch other images than initial chosen dimensions (in our case it’s 158×158 – in your case they can be different). Leave them dynamic (in our case we can allow us one more hack – remove dynamic images from the large ones in slide show as far as we create all large images exactly 550×226).

Results

Here we (with the help of internal WordPress tools) replaced almost all of dynamic images with static ones. This should help us to merge them together and make our website more robust. Here we have saved about 13×4 ms = 52 ms with every new visit. And this is 2.5x more than expenses to serve a HTML document for our website.

Client side speedup isn’t as large as server side one (because he have highly parallelized load flows) – it’s about 4-10 ms here. Or nothing.

Related Posts

• February 11, 2010 -- Hacking timthumb.php – all the best practices (3)
• February 21, 2010 -- HTML Sprites – new weapon against HTTP requests (2)
• January 23, 2010 -- CSS Sprites: revealing sealed mystery (1)
• January 21, 2010 -- Add more caching with (background) images (0)

This is the third post in our website performance optimization journey Stage 3. In the previous parts we reduced data:URI (CSS) size and minified HTML. Now we are going to move all resources to cookie-free domains and somehow measure the difference.

Basics

Why cookie-free domains are good? Here is a very detailed investigation how cookie (headers) size can affect website load speed. In our case cookie are not so big (their actual size is bytes) but we can still save some visitors time with their minify.

How can we minify cookie size? Well, actually no way. But we can eliminate cookie usage for static assets if we place such assets to different (from our website) domains. Something like static-youwebsite.com (note, it’s not static.yourwebsite.com – another sub-domain, but another first-level domain).

And how can we implement such solution?

Implementation

Actually we need either to register another domain and mirror our static resources to it. Or use some ready solutions (such as Google CDN or 2static.it, or another CDN). The last one actually offer you a mirror domains which you can point to your website and get all benefits from parallel images loading without sub-domains usage.

We are using WEBO Site SpeedUp (as an external application, but WordPress plugin has the same features) to distribute images through multiple domains (not sub-domains but completely external domains).

Here we have used 3 static domains (what is quite enough for our 20 images). And how much have we got?

Actual load speed should be improved very slightly. And it can be hardly measured. As far as we have not so big cookie size – and about 3 chunks in page load (due to multiple domains usage) forecasted gain should be about 3 * 3 ms = 10 ms. So it’s less than average fluctuation in load speed measurement (100 ms). Right now our website for a new visitor is being loaded in 3.7 seconds, so we can’t get anything from cookie-free domains usage.

Even if we would have cookie size about 4 Kb with multiple domains we get about 100-150 ms gain, What is actually about 2-3% speedup and doesn’t worth to be implemented.

Small bonus

We have also added dimensions for our HTML images (to improve Page Speed grade because we can’t improve YSlow grade from 90 – can’t affect our website headers due to absence of mod_headers here, but can affect number of static assets – this will be covered in the next posts).

So how to implement dimensions setting for Basicpress theme (and maybe some others with timthumb library). We are going to wp-content/themes/basicpress/index.php and on the line 8 (where img is inserted) replace

 border="0"

with

 width="158" height="158"

Maybe better will be done this via CSS usage. But it works anyway.

Also we should make almost the same changes in wp-content/themes/basicpress/header.php (please take into according actual image sizes, i.e. for slide show we have 550×226 and 48×48 – for bigger and smaller ones. We are not touching wp-content/themes/basicpress/sidebar.php because we are going to move image from Popular posts widget to our CSS Sprites / CSS background images.

After this piece of magic we will have significantly less warnings about not set images’ dimensions in Google Page Speed extension for Firebug/Firefox (and a bit improved usability for our website). ANd its grade is now 96/100. That’s great!

Conclusion

After multiple domains usage cookie-free domains are not efficient (even if you have large amount of cookies per each HTTP request). Moreover if you have small cookie size – you will get no actual speedup after this technique implementation.

Related Posts

• January 29, 2010 -- Reviewing speedup – from advanced to extreme website acceleration (0)
• January 27, 2010 -- Parallelize images – multiple domains in action (0)
• March 7, 2010 -- Dynamic CSS / JavaScript files are evil – 8 reasons (4)
• February 26, 2010 -- All about WordPress performance – 11 golden rules (1)

Let’s review today such a contradictory point in website acceleration as HTML minify. It’s one of our steps to bring extreme performance to our website. And it can reduce load time not only for the first-time visitors, but also for returned ones and if readers are going to the next posts in our blog – for second pages and so on.

HTML minify challenges

Well. It seems be very simple – just remove all unnecessary symbols from HTML code. But what symbols are excessive? First of all – all line breaks and double spaces. But should we remove really all of them? The correct answer is – no. We can’t remove for sure any symbols from tags pre, textarea, and script to reduce overall HTML code size.

OK. We can leave these tags as they are. What else? Also we can’t touch aggressively line breaks inside inline elements (or between them) – because they are equivalent to spaces (per contra we can safely remove all space-like characters between block elements without any actual losses).Well… The hour is not easier.

Also we can remove HTML comments if they are not served to IE browsers (because latter can parse conditional comments). Or we should remove all comments exclude conditional.

Practical solution

There are a lot of reefs and too little possible gain. You can apply all HTML minify actions by hand (through your template code and blog posts). But this isn’t worth expected speedup.

You can also try to implement some (semi) automated solutions. But please don’t use W3 Total Cache plugin for aggressive HTML minify – it can break your layout. WEBO Site SpeedUp which is being used for this website has complete support for all actions to minify data size including HTML documents.

Let’s try to enable HTML minify, Remove HTML comments (conditional comments are removed for non-IE browsers only), and ‘HTML-to-1-string’ options. Here is final YSlow chart.

In comparison with the last performance situation we have eliminated 0.6 Kb (remember – we are already using gzip compression), which is about 11% from HTML document and about 0.15% from page load speed. But it’s valid only for new visitors.

For returned visitors (is they have all the other resources cached – CSS, JavaScript, images) we have here 10% additional speedup. Except HTML document we have only small Google Analytics GIF-counter, which loads rather quickly. But in case of loading all assets from cache we face with rendering expenses. And actual speedup here will be less (we will try to count it in the future with rendering measurement).

Conclusion

HTML minify isn’t worth to be implemented for a common website. It does too little and can be very CPU (or time) expensive. If you are already using some strong caching solution – it’s better to include HTML minify to it. In all the other cases you can leave this WordPress performance optimization practice for geeks only.

Related Posts

• January 19, 2010 -- Too many styles? Shrink them! (1)
• January 17, 2010 -- Less files – faster website, but how much? (2)
• February 26, 2010 -- All about WordPress performance – 11 golden rules (1)
• January 29, 2010 -- Reviewing speedup – from advanced to extreme website acceleration (0)

In the previous post we set plan to bring our website to the extreme performance level up. First of all we need somehow cut our styles (mostly to reduce amount of data:URI). Usually this operation doesn’t bring much web performance, but not in the case of base64-encoded images in CSS files.

What to start with?

We can use either Page Speed plugin for Firebug/Firefox, or Dust-me Selectors directly for Firefox to find CSS selectors which must be removed.

Our main criteria for now will be YSlow statistics chart – and size of the CSS files.

In our case all is very simple – we need to clean up GD Star Rating styles from unused stars / thumbs. OK, going to GD Star Rating plugin settings and remember what sets do we have enabled there. In our case all stars are under ‘Soft’ set. Also you need to remember which star sizes are actually used (in our case it’s 24 – for big ones – and 16 – for small ones). Also we don’t use thumbs in ratings.

Fixing GD Star Rating

After we have remembered all options let’s go to wp-content/plugins/gd-star-rating/css/gdsr.css.php. It seems that author tried to remove unused styles from dynamic styles generation. But without any actual success – generated CSS file link includes all possible sets and all possible sizes. We need to fix this situation.

So in file wp-content/plugins/gd-star-rating/css/gdsr.css.php find $type == "s" (near line 88) and replace this piece of code

if ($type == "s") {
	$folders[] = substr($r, 3);
	$sets[] = $set;

with this one

if ($type == "s") {
	if ($set['folder'] == 'soft') {
		$folders[] = substr($r, 3);
		$sets[] = $set;
	}

Here we added our stars’ set (’soft’) and restrict adding to the final array any other sets. If you use different set – use its name here.

Then a bit lower we need to cut all other arrays from unused values. So just before the line with

echo "/* stars sizes: ".join(", ", $sizes) ." */\r\n";

add the following

$sizes = array(16, 24);
$thumb_sizes = array();
$thumb_sets = array();

Here we cleaned up arrays with thumbs and restricted array with sizes to our actually used ones (16 and 24).

And the final change (actually to reduce amount of different data:URI chunks, not to reduce amount of CSS rules) is near line 154-159. Find there

foreach ($sets as $set) {

And replace this piece of code

echo $class." .starsbar.gdsr-size-".$size." .gdouter { background: url(...";
echo $class." .starsbar.gdsr-size-".$size." .gdinner { background: url(...";
echo $class." .starsbar.gdsr-size-".$size." .gdcurrent { background: url(...";
echo $class." .starsbar.gdsr-size-".$size." a:hover { background: url(...";

with this one

echo $class." .starsbar.gdsr-size-".$size." .gdouter{background:repeat-x 0 0}\r\n";
echo $class." .starsbar.gdsr-size-".$size." .gdinner{background:repeat-x 0 -".(2 * $size)."px}\r\n";
echo $class." .starsbar.gdsr-size-".$size." .gdcurrent{background:repeat-x 0 -".($size)."px}\r\n";
echo $class." .starsbar.gdsr-size-".$size." a:hover{background:repeat-x 0 -".$size."px!important}\r\n";
echo $class." .starsbar.gdsr-size-".$size." .gdouter,\r\n".
  $class." .starsbar.gdsr-size-".$size." .gdinner,\r\n".
  $class." .starsbar.gdsr-size-".$size." .gdcurrent,\r\n".
  $class." .starsbar.gdsr-size-".$size." a:hover{background-image:url('".$url."')!important}\r\n";

Results

Here we have saved 75 Kb of data (and now can merge our CSS files back) – most of this amount was related to data:URI in unused CSS. But during styles cleaning we have found missed background image (blue splash), which must be somehow minified. After converting from JPEG to PNG we have saved additionally 30 Kb but it’s still too large. Need to think how the situation can be improved here.

We have not finished yet with unused selectors – but with large chunks of unused data maybe. In one of the next posts we will completely review how you can determine and remove really unused CSS rules (because 1 CSS file can be applied for different website pages, and each page doesn’t have all DOM elements which are described in CSS).

Conclusion

Removing unused styles can help you to speed up your website, sometimes even significantly. In our case simple actions have saved 75 Kb of data, or about 20%. Also this should increase page rendering speed but not so notably (we will check later how it increases in this case – but it’s about 10 ms gain).

Related Posts

• January 29, 2010 -- Reviewing speedup – from advanced to extreme website acceleration (0)
• January 21, 2010 -- Add more caching with (background) images (0)
• January 20, 2010 -- data:URI is the next generation of acceleration techniques (2)
• March 7, 2010 -- Dynamic CSS / JavaScript files are evil – 8 reasons (4)

Yesterday we completely finished with our performance optimization Stage 2 (advanced techniques). Let’s review how much acceleration we have got during this process.

Actual progress

As you can remember we have website load time about 4.2 seconds (clean cache) and the following YSlow chart.

Now we have a bit better situation (with load time about 3.8 seconds).

Minus 29 HTTP requests, minus 25 Kb in size (but please note that we have now 1 banner – about WEBO Site SpeedUp, which is about 10 Kb). So we have achieved about 10% more speedup for new visitors (and about nothing for returned visitors). It seems there is something wrong (we planned to get 20-30% over Stage 1 speedup).

All applied actions, one-by-one:

• Merged, compressed, and delayed JavaScript files. About 6% of speedup.
• Merged and compressed CSS files. About 5% of speedup.
• Applied data:URI, mhtml, and delayed data:URI. About 17% of speedup.
• Used aggressive background images. 4% more speedup.
• Used CSS Sprites. No actual speedup over dataLURI (just more dynamic interface maybe).
• Replaced dynamic images with static ones. Less than 1% speedup.
• Used multiple domains. About 5% more speedup.

A simple sum from these actions gives us 38%, but we have got only 10%. What’s wrong?

Also we have approval picture from Google Webmasters that almost nothing was changed with our WordPress website load speed.

Analyzing drawbacks

Actually a lot of information goes from understanding what actions were applied and what each of them brought to our website. The worst thing here is… data:URI. This technique includes into our CSS file (the second one, with all background images) a lot of excessive base64-encoded data. This was happen due to not properly tuned data:URI usage and bad GD Star Rating plugin behavior (instead of including only required styles to the final CSS file this plugin includes all possible what makes this file much bigger).

But let’s take a look to Page Speed analysis (it’s under Firefox 3.5.7, since 3.6 doesn’t support this plugin yet).

Almost all of yellow (medium warnings) points can give us a little speedup. But ‘Remove unused CSS’ seems to cut our resource CSS file by about 50% (26 Kb). It seems it’s the point – our lost 28% of speedup.

Planning new actions

We are going to improve our website load speed step by step, analyzing and evaluating all possibilities. For now we have tried a lot of different methods and see actual result. Let’s prepare new list of actions with possible acceleration.

1. Remove unused CSS. We will get here (due to data:URI usage) about 15% of speedup.
2. Server static content from 3rd-party domains (we mentioned 2static.it service, maybe it can help?). About nothing here (less than 1% of speedup).
3. Try to combine HTML images on the home page (i.e. just thumbnails) + or move some of them to CSS background. We will save here also about nothing, less than 1%.
4. Page Speed also talks about dimensions for our images on the home page. Most of these issues will be fixed with the previous point, but we should somehow measure actual speedup here – we will review how to measure page rendering in browsers.
5. Also we should try to apply HTML minify with already gzipped HTML documents. Maybe this will save about 1-2% of load speed.
6. …And? Yes, maybe ‘Efficient CSS selectors’. But probably we will leave them for Stage 4. And we will try to add 2-3 Google AdSense blocks to the website and see how they influence our website load speed. And how can they be made unobtrusive (non-blocking, delayed).

OK. It seems we have a great plan for the next week

Conclusion

Advanced website performance actions can give about 30-50% (after 300% speedup from basic ones), but it will take more time and require more knowledge to use all techniques (i.e. data:URI) properly. And even after all these techniques have been applied you still have some stuff to improve. And we will review it in the next blog posts.

We are going to make our website extreme fast. Are you ready? Fasten your seat belts!

Related Posts

• January 21, 2010 -- Add more caching with (background) images (0)
• January 20, 2010 -- data:URI is the next generation of acceleration techniques (2)
• February 26, 2010 -- All about WordPress performance – 11 golden rules (1)
• February 21, 2010 -- HTML Sprites – new weapon against HTTP requests (2)

We reviewed multiple hosts application to our website and get a little more speedup. So let’s see how CDN (Content Delivery Network) can help us.

Actually CDN is a large number of servers which are distributed all over the world and have very good connection timings (so every HTTP request costs about 1-2ms). This will greatly help if your website has a lot of small objects (CSS or JavaScript files, background images, etc). But what if we have about 20 objects per page with an average size of 20 Kb?

Measuring performance

Here we have HTTP waterfall picture for our website (it’s YSlow, but you can get with any of client side performance measurement tools).

Well, here we have 8 chunks of data loading – HTML document, 1st CSS file, 2nd CSS file, 2 chunks of images, then Google Analytics library, then CSS Sprites, then Google Analytics counter (transparent 1-pixel GIF file). But to show page on a screen (blue line here) we require we really have 5 chunks of data (Google Analytics library seems to use it’s own DNS, so it’s better to keep in unchanged).

If we are going to cache HTML document (which can be potentially dangerous) – we can influence here (on a well-accelerated website) only on 5 consequent steps of HTTP requests (so if we eliminate all server side delays and our HTTP requests will return at once – we will save here only 5*gain due to concurrent requests to images).

We measured actual server delays a few days ago so we can say for sure that overall load time will increase by

5 chunks * (15 - 1) ms = 70 ms

Total web page load speed won’t be influenced much with CDN usage. It’s like any other methods in Stage 2 – only 3-5%.

Please note: these calculations are valid only if you have applied all first priority client side optimization actions (including client side caching). If you have huge time to generate your HTML document, dozens of JavaScript or CSS files, a lot of background images – CDN will be a ’silver bullet’ for your website. But actual speedup can be achieved even without it.

Moreover CDN usage can be replaced with multiple hosts (actually it’s not the truth, but in the first approach it’s right) – you can reduce Cookie size sending to get static resources and reduce efficient delay to get any of your resources (usually – static images).

WordPress plugins

If you are using CDN there are some WordPress plugins which can help you to replace URL for your static assets with CDN-equivalents.

The first is W3 Total Cache. It has quite a lot of options to enable CDN support.

Not sure if all of them are very useful but with enabling CDN support some of the resources were distributed to i1 and some were not. Maybe it uses 2 hosts by default for distribution (www and defined one).

The second one – WEBO Site SpeedUp – has less options but still can be used to automate CDN distribution (according to this blog post). You can just setup only 1 host in Multiple hosts group of options.

And get all images re-linked to CDN. Also you can re-define default website host in System Status.

This will turn on distribution for merged CSS and JavaScript files (if it’s required).

Conclusion

For well accelerated website CDN can be useful only as a caching level. Actual speedup will be about 100 ms what is less than after simple CSS files merging. But if you are looking to bring extreme performance for your website you should consider CDN usage. Also there are a number of WordPress plugins to automate CDN integration into WordPress website.

Here we are finishing with Stage 2 (advanced web performance optimization) for our website. We will review savings and schedule next stage 3 – really high performance – with the help of cutting edge technologies and tools.

Related Posts

• January 19, 2010 -- Too many styles? Shrink them! (1)
• January 17, 2010 -- Less files – faster website, but how much? (2)
• January 15, 2010 -- 40x speedup with server side caching, which one is the best? (0)
• March 7, 2010 -- Dynamic CSS / JavaScript files are evil – 8 reasons (4)

Yesterday we prepared our dynamic images to be distributed among the static ones. Let’s see how this can be implemented.

First of all what will we gain after images distribution? On the home page we have 19 images (and about 12 on every blog post one). Actually there are 17 images, 1 CSS image (yes, our prepared CSS Sprite), and 1 favicon (which can’t be distributed efficiently – it will be requested from the main domain as well). As far as browsers use about in average 4 connections per hostname, there will be about 4-5 chunks connections on load waterfall.

It looks like this waterfall.

Browser has to wait until connection is ready to be used. So this adds delay to the page load process.

How to use multiple hosts

The simplest way to eliminate these delays is to use multiple domains (because it’s ‘per host’ limit) with the same pictures. And this speed website load up. You can check post about caching various types of data, there were reviewed possible ways to use some free CDN-like resources to provide caching for static assets. This also can be used to distribute images (you can for example place all of them to Picasa and use its own distribution logic).

But our post isn’t about using some external resources. We are going to implement some domestic solution (to integrate it into our blog once and use all the time).

Preparing static mirrors

To work efficiently with multiple hosts distribution you need to add some hosts to mirror your main one (of course you can us more complicated scheme – i.e. point new host to a specific directory on your web server – but this requires direct access to configuration file what can be impossible for shared hosting). First of all you need to add a few records to DNS (if you don’t know what is it – you can just try to use great service 2static.it which allows you to create such aliases via web interface for any host).

Note: to add proper records to DNS you need

• Either add A-type record, for example
  

  i1 IN A X.X.X.X

  Where i1 is a desired host for your website mirror (i1.speedingupwebsite.com) and X.X.X.X is your website IP address (you can get it with simple ping yourwebsite.com in command line or with any of SEO check tools).

• Or add CNAME-type record like
  

  i1 IN CNAME yourwebsite.com

If you have any troubles with static aliases setup your can write to your hosting provider support or check how this can be performed via hosting administrative panel (usually there are some tools).

OK. After we have chosen 2-4 domain names on 2static.it or have added aliases to DNS we need to check their availability and request some resources from them. For example images. So this request

http://i1.yourwebsite.com/wp-content/themes/basicpress/images/some.image.png

must show you exactly the same image as the following one

http://www.yourwebsite.com/wp-content/themes/basicpress/images/some.image.png

Here we have i1 – your chosen host (one of the 2-4 prepared) – and yourwebsite.com – your website domain.

Well. We are ready to implement these static mirrors to our website templates.

Handy solution

Well, let’s try to implement some kind of solution ‘by hand’. First we should analyze current website structure and somehow distribute images in our mind. So all (6) images from the top slide show can be served from 1 host, and 10 thumbnails on the home page for posts can be server via 2 another domains. Also we can still have the main one – www.speedingupwebsite.com – as one more mirror (it’s not very good, because we will have cookies sent for it, but eliminates one more DNS request). So there are totally 3 more domains. Also we can leave pictures in posts themselves on the main domain – posts are large in height and images’ load sped isn’t crucial here.

A question: why shouldn’t we implement 10+ static hosts – to guarantee extreme website performance even for IE7- wit 2 requests per domain? Because every new web host requires DNS request. Which isn’t cached for a new visitor (but for returned visitors we already have client side cache). So we reduce delays but payload in the number of DNS requests. And Yahoo! showed that optimal number is about 2-4.

OK. So we need to find where slide show images are called from. In our case it’s the file wp-content/themes/basicpress/header.php. Here we change all occurrences of

<img src="<?php bloginfo( 'template_directory' ); ?>

to

<img src="http://i1.yourwebsite.com/wp-content/themes/basicpress

i1.yourwebsite.com is a mirror we have added a bit earlier. Here we had 4 such places to change.

OK. Let’s check our website – all top images are loaded from this mirror. That’s great.

The second fix (to distribute posts’ images on the home page) will be in wp-content/themes/basicpress/index.php. Almost the same changes.

<img src="<?php bloginfo( 'template_directory' ); ?>

to

<img src="http://i<?php echo ($post->ID % 2)+2 ?>.yourwebsite.com/wp-content/themes/basicpress

In this example we try to set a permanent web host for each post image (because it’s not very good to change hosts for the same images in terms of content). So we connect host to post ID (and use 2 mirrors only – i2 and i3).

Congratulations. We have distributed our images through multiple hosts.

Automatic distribution

Steps described above can be a bit complicated if you have not just a simple blog. Or have 20+ images on the home page. So here we can use some automated systems.

We will cover CDN and WordPress plugins to distribute images in details in the next post. But to end with image distribution for now we can just implement WEBO Site SpeedUp group of options.

Every image will be linked to its own host (it won’t be changed from page to page or update to update), and this will force all images on your website (not only on the home page, or only in slide show) to be mirrored. Very easy.

So after this implementation we have the following load diagram.

What looks much better in terms of client side performance.

Conclusion

Multiple hosts are not very easy to be implemented (because in every case your need to add some static mirrors for your website). And they don’t bring much performance in modern browsers – this technique works very well only in old IE. But in any case with it we can gain about additional 200ms, or 5% for our website load speed. This speedup isn’t critical (it doesn’t affect time of the first page appearance in visitor’s browser) but helps to bring extreme performance for our website.

This is almost the last part of our Stage 2 of the performance optimization process. We are going to finish it with a complete review this week.

Related Posts

• February 3, 2010 -- Are cookie-free domains efficient? (1)
• January 29, 2010 -- Reviewing speedup – from advanced to extreme website acceleration (0)
• March 7, 2010 -- Dynamic CSS / JavaScript files are evil – 8 reasons (4)
• February 26, 2010 -- All about WordPress performance – 11 golden rules (1)

Just to remind: we are going through WordPress performance optimization stage 2 (after 3x speed from Stage 1) and focusing on decrease of number (or payload) of HTTP requests. Last several posts were devoted to CSS images optimization. We reduced their number and reviewed some well-known techniques to perform this automatically (or semi-automatically).

Before we start with actual HTML images distribution through multiple hosts (yes, it’s the most powerful technique here) we need to prepare our thumbnail library – timthumb – to be more fast and reliable.

Why dynamic images are evil?

Frankly speaking it’s very convenient – to upload only one image to the website and create thumbnails of any size from it. But let’s reveal this anti-pattern of web performance optimization. For this image (from the last post)

We have the following timings (get by webo.name).

Here we have about 12ms – it’s too much (but we remember – we are working on a weak shared hosting, it’s a miracle that website can load so fast here) for server side expenses. And for a dynamic equivalent for this static image we have the following figure.

It’s about 8ms difference. It’s not so much, isn’t it? Really? For the home page we have 3 large dynamic images (slide show) and 3 smaller (for the slide show too). 16 images x 8ms = 128ms. It’s still not so much but if we compare these expenses with our home page (and every HTML cached page) timings we can see that dynamic image generation ‘eats’ more than 6x from just HTML document response time.

And with every hit to the home page we lose 130ms (and can’t serve 5x more hits with our shared hosting). Please note – this is about home page, pagination and archives pages (with a lot of thumbnails) only. On single post pages there are only 6 such images – mush less but still 2x losses.

How to fix this?

Well the idea is clear enough. We need to create mnemonic file names for each dynamic image (as you remember we actually enabled their caching on Stage 1). And then just add little rewrite magic to .htaccess (sorry if you are not using Apache, maybe you can create the same rules for nginx, lighttpd, or something else) to check cached thumbnail existence and serve it instead of calling dynamic script.

Starting with timthumb.php

We are going to wp-content/themes/bacipress/ (it’s our timthumb.php actual location – it seems to be in the curent theme folder). Cache files are named like md5 hash. So let’s look for a function md5 whch can perform such transformation.

On the line 338 there is

$cache_file = md5( $cachename ) . '.' . $ext;

It seems it’s what we are looking for.
File name is calculated in these 2 lines (this one and the one above).

$cachename = get_request( 'src', 'timthumb' ) ...
$cache_file = md5( $cachename ) . '.' . $ext;

So we need to change logic of $cachename creation. And remove md5 (because md5 sum calculation with every Apache redirect will be very heavy). These two lines have been transformed to

$filename = preg_replace("@http://[^/]+/(.*)\.$ext$@", "$1", get_request( 'src', 'timthumb' ));
$cachename = $filename . '-' .
	get_request( 'w', 100 ) . '-' .
	get_request( 'h', 100 ) . '-' .
	get_request( 'zc', 1 ) . '-' .
	get_request( '9', 80 );
$cache_file = $cachename . '.' . $ext;

There are several changes:

• We have added correct file name calculation (from the website root) – and removed from it actual file extension (because we need to add some parameters, and this extension is added a bit lower).
• We have just added dashes in $cachename for better readability.
• And we have removed md5 from $cache_file.

So we have replaced initial 2 lines with these 7 ones.

Also we need to change default cache directory to the website root (so all thumbnails will be placed exactly near source files). It’s line 39 in file timthumb.php:

$cache_dir = './';

Please change it to the following one.

$cache_dir = '../../../';

OK. Now all our images are placed regarding there location in the website structure. It’s a half of our optimization.

Finishing with .htaccess

The last part is to add some RewriteEngine magic to our .htaccess. Let’s find there the following strings (in BEGIN WordPress part).

RewriteEngine On
RewriteBase /

The last one can be commented or absent – it isn’t required if we are working with WordPress located in the document root of the website. OK. Please insert here (under these rules) the following lines.

RewriteCond %{SCRIPT_FILENAME} timthumb\.php
RewriteCond %{QUERY_STRING} src=http:\/\/[^\/]+\/(.*)\.(png|jpe?g)&w=([0-9]+)&h=([0-9]+)&zc=([0-9]+)
RewriteCond YOUR_HOME_DIRECTORY/%1-%3-%4-%5-80.%2 -f
RewriteRule .* /%1-%3-%4-%5-80.%2 [L]

This can be a bit complicated but let’s review what they perform. The first one

RewriteCond %{SCRIPT_FILENAME} timthumb\.php

checks if any dynamic image (served via timthumb.php) is requested.

The second one

RewriteCond %{QUERY_STRING} src=http:\/\/[^\/]+\/(.*)\.(png|jpe?g)&w=([0-9]+)&h=([0-9]+)&zc=([0-9]+)

computes GET parameters (from query string) to get image file name, its extension, width, and height. Please note there is no quality parameter. If your images URLs look different (with additional GET parameter) please add it to this rule.

The third one

RewriteCond YOUR_HOME_DIRECTORY/%1-%3-%4-%5-80.%2 -f

checks if there is file with requested name (we create such files after the first request with fixes to timthumb.php described above). Variables (%1, %2, %3, %4, %5) are computed from the second rule (expressions in curly brackets).

Small note: how to get your home directory? Some of WordPress plugins can your this information but you can also create in the website root a file rootdir.php with the following content

<?php echo $_SERVER['DOCUMENT_ROOT'] ?>

and copy its output (after you open it in browser). It will be YOUR_HOME_DIRECTORY. Please don’t forget to delete this file after you get this info.

And the last Rewrite rule

RewriteRule .* /%1-%3-%4-%5-80.%2 [L]

just redirects (internally, without no subsequent redirect – flag [L]) to the end file name. Great.

All this has resulted into less response time.

Not 12ms for the really static file but also not 20ms for dynamic (cached) image.

Conclusion

With quite a few changes in timthumb.php and .htaccess we can gain a bit more performance from our website and get it ready for multiple domains usage (which will be discussed in the next blog post). For the home page actual savings are about 15-20ms, or less than 1% (because all images are load in 3-4 chunks of parallel flows). This improvement can save a bit for dedicated server but for a shared hosting it improves the whole website efficiency (because we save server expenses and can show more pages to our visitors without overload).

Related Posts

• January 8, 2010 -- The right way to speed up your blog (3)
• January 7, 2010 -- Is my WordPress blog fast enough? (part 2) (4)
• January 6, 2010 -- Is my WordPress blog fast enough? (part 1) (4)
• January 15, 2010 -- 40x speedup with server side caching, which one is the best? (0)

In the last post we reviewed CSS Sprites technique usage but we didn’t mention all possible ways to use CSS background property including different image formats. Let’s deep into this area and list all possible combinations where background images can be used.

Simple usage

Some applications were reviewed a day ago – we can define for our image width and height, and place as a background image with the same width and height. As you can remember from post about moving images to CSS background we can operate with small images like this one.

And add for them styles like these rules.

.img_rss32 {
	width: 32px;
	height: 32px;
	background-image: url(/wp-content/themes/basicpress/images/rss_32.png);
	background-repeat:  no-repeat;
}

Here we have an image (RSS icon) 32×32 and create placeholder for it (.img_rss32) with the same dimensions.

This situation is very common for buttons and rollover effects. At the end of design to HTML transformation you can have dozens of images with identical dimensions. And all of them can be simply merged. As an example we will take a CSS Sprite from the previous post.

To cut a RSS icon from this image we need to get somehow (is you calculate coordinates during CSS Sprite merging or use automated services – this shouldn’t be a trouble) its top-left position. In this case it’s 92,0. That’s great.

Then we need to shift background image in backward direction to fit this position. Our styles will look like

.img_rss32 {
	width: 32px;
	height: 32px;
	background-image: url(/wp-content/uploads/2010/01/webo.256d549f4a.png);
	background-repeat: no-repeat;
	background-position: -92px 0;
}

And here we have our positioned background image.

Please note that we can place any number of images together if we deal only with such simple usage of background images. But please note that there are some side effects on scaling such elements. So please add a few transparent (or with proper background color) pixels around initial images (5 will be enough).

Styling lists

Lists often have custom bullets. To make them cross browser they are placed with the help of background images. Simple example:

li {
	background-image: url(list.png);
	background-repeat: no-repeat;
	background-position: 0 10px;
}

Well. Here we have (a) element with no dimension properties (width / height) and (b) initial background position. The second point can be defeated if we just shift out initial image (list.png) to this position to leave enough free space. But what can we do with the first point?

So while creating HTML/CSS code from initial design mockup we must think how to optimize it in the future. And set dimensions for our elements with background images in all possible cases. So tools like SpriteMe or Auto Sprites can parse these rules easily.

But let’s return back to our situation. We can’t safely merge such images (with undefined dimensions) as far as content can enlarge and visitors will see other images revealed.

Here is content in the red rectangle, and images from CSS Sprites are ‘broken’ (shown incorrectly). So what we do in this case? First of all – define strict limits for our containers. If we can’t – we can place all images suing enough space (i.e. if your containers are limited horizontally you can place your icons one by one horizontally). Also you can try to place them vertically (like in this example) and hope that there won’t be so much content.

But is there the universal solution? Definitely yes. You can place all background images in such order.

This guarantees that any amount of content won’t break your layout.

Calculating percentages

This part is even more complicated than previous one. Because we may deal not only with absolute background-positoon. It can be also set in per cent. And how such images can be merged into Sprites?

If you are really interested in CSS Sprites generation and best practices you must read Steve Souders thoughts about SpriteMe creation (part 1 and part 2). These techniques can be really hard for beginners and should be left for professionals or persons who are trying to be them.

In a few words we know absolute dimensions of container element and can re-calculate background-position to absolute values. Then handle images as described above.

Also there should be mentioned that not all cases can be converted to CSS Sprites. For example there can be an image placed to an element with not defined (or floating) dimensions with

background-position: 100% 100%;

This prevents efficient CSS Sprites usage. Also cases with 50% 50% are usually not convertible.

PNG8, PNG32, and animated GIF

Different image formats add little more mess to CSS Sprites creation. At this moment all images with 256 colors (and 1-bit transparency) can be safely converted to PNG (yes, without gAMA and all the other chunks to prevent any color inconsistency bugs in browsers). But usually CSS Sprites contain dozens of images. So 256 colors will be not enough to perform this. And we will need to use PNG24.

Using PNG24 be careful with alpha channel. Maybe it’s safer to separate semi-transparent images from the others and place them in different CSS Sprite.

A few words about animated GIF. It seems they can be safely merged only with other animated GIF images. Because GIF images are usually bigger than PNG equivalents. And please don’t create CSS Sprites in GIF. It’s an old school terrible practice.

Conclusion

In this post we haven’t achieved any acceleration for our blog but reviewed some best practice to prepare our website to the extreme performance (and avoid additional handy work). CSS Sprites seems to be very useful approach to reduce number of HTTP requests. But they must be replaced with easier techniques, such as data:URI packets or something similar.

But before we have 99% of browsers supporting such techniques we have to use CSS Sprites. So you are forewarned is forearmed. And don’t create stupid CSS leading to awful CSS Sprites

Related Posts

• January 29, 2010 -- Reviewing speedup – from advanced to extreme website acceleration (0)
• January 23, 2010 -- CSS Sprites: revealing sealed mystery (1)

Last posts figured out how to use data:URI combined approach (parts 1, 2, 3). The last one actually was related to improving overall website caching not just base64-embed images. And this will help us to create CSS Sprites properly.

CSS Sprites is an important part of overall website acceleration process because (like data:URI) it allows you to create a few objects from 100+. And therefore reduce number of HTTP requests which are required to get the layout data of our website. Actual number of CSS Sprites images can be only 2-3 but they can be loaded in parallel and don’t delay somehow page load (because CSS Sprites are raw images and are not CSS or resource files).

What are CSS Sprites?

There are a lot of articles about this revolutionary approach. Really. You can start with classical ‘Image Slicing’s Kiss of Death’ (A List Apart) and go on reading manuals, reviews and how-to (also you can refer to this good article on Smashing Magazine). In a few words CSS Sprite is a combined image which contains 2 or more different background images. Latter images are cut from the CSS Sprite with the help of background-position CSS property (or sometimes via clip).

For example let’s take this image

And apply it as a background image for these 2 classes:

.sprite1 {
	background-image: url(.../cdn_smash/images/css-sprites/button.gif);
	background-repeat: no-repeat;
	background-position: -157px 0;
	width: 157px;
	height: 27px;
}
.sprite2 {
	background-image: url(.../cdn_smash/images/css-sprites/button.gif);
	background-repeat: no-repeat;
	background-position: -314px 0;
	width: 157px;
	height: 27px;
}

And then just insert <div class="sprite1"></div> and <div class="sprite2"></div> here:

As you can see both div have the same background image but look different. The magic is in the position of the background image and blocks’ width (which is also used to cut initial background image).

Tools to create CSS Sprites

Now there a large variety of different tools, more or less known. You can start with these handy ones – spritegen.website-performance.org or css-sprit.es. With these tools you need to upload all images and get them placed somehow (hopefully correctly). Also you can’t add there initial CSS rules – you just get final ones.

Smart Sprites (csssprites.org) are much better. They allow you to upload only a prepared CSS file (with absolute paths to images) and get it with CSS Sprites included. But you need to add some more meta information about images to get them merged correctly.

There is also a completely automated approach which was presented last year by Steve Souders. It’s SpriteMe. You just need to open your website in browser, run this tool and get all images distributed via a few CSS Sprites + a pack of CSS. Then you need to save images and add new styles. No preparations – just run and apply. Very easy.

If you are looking for a server side approach – there is sprites.in. Based on CSS Tidy parser gets all CSS rules and prepares final CSS Sprites according to these rules. Actually no more than 3 images are created from 100+.

WordPress plugins

There is one plugin – cSprites – but it creates not CSS Sprites but HTML ones (Image Maps). All images on website page are replaced with a transparent gif file with the same size but different background. And all images are combined into one.

As an example – here is a Sprite from the previous post. All there images are combines into 1 (57 Kb in size).

This approach is generally good but can’t be used with a lot of images. Also it’s not applicable for the whole website – different images are created for each page. And if you have some layout images – they will be added to each Sprite (we discussed how to move images from HTML to CSS, this can help).

Also due to large images this plugin will be very costly for server side (in terms of memory). With our restriction in 32 Mb home page was broken during such WordPress performance optimization. And there is no option to restrict images by file name or size.

And finally computed styles are inserted via JavaScript (document.write) into document body. This definitely freezes rendering and such images appearance.

WEBO Site SpeedUp

But speaking about completely automated CSS Sprites we must mention one more WordPress plugin. Frankly speaking it integrates functionality of sprites.in tool but brings to a new level. It also has large variety of options for CSS Sprites processing (restriction by size or filename). We definitely need to cover CSS Sprites tuning with the help of this plugin in the next blog posts.

But now we have just tried to create a sample (yes, we have a few background images appeared after moving them from HTML to CSS). And our final Sprite image looks like the following one:

It seems the whole logic works almost perfectly – the image isn’t too large and all transparency is handled properly. Great. But what’s about our website speedup?

If you compare it with the previous one

you can see that for our website (after data:URI over CSS Sprites with WEBO Site SpeedUp) we have 9 Kb more data. It seems in our case CSS Sprites are useless. But if final images are greater than 24 Kb (IE8 data:URI size restriction) – they will be loaded as plain images what should increase concurrency of load flows. And please also take into accordance that IE7@Vista supports mhtml (base64-encoded images) badly. So we still need to use CSS Sprites for this browser.

Conclusion

CSS Sprites is a very powerful tool to increase website load speed and decrease number of HTTP requests. There are several approaches (handy and automated) to create them but be careful with website size, memory limits, and compatibility. We will analyze correct CSS Sprites creation process and drawbacks of such approach (yes, there are several onew) in the next posts.

Rating: 9.0/10 (1 vote cast)

Related Posts

• February 21, 2010 -- HTML Sprites – new weapon against HTTP requests (2)
• January 21, 2010 -- Add more caching with (background) images (0)
• February 26, 2010 -- All about WordPress performance – 11 golden rules (1)
• January 29, 2010 -- Reviewing speedup – from advanced to extreme website acceleration (0)

]]> http://www.speedingupwebsite.com/2010/01/23/css-sprites-revealing-sealed-myster/feed/ 1 http://www.speedingupwebsite.com/2010/01/23/css-sprites-revealing-sealed-myster/