Category Archives: Website Performance

Cloudflare in review

Cloudflare analytics

Cloudflare has been running on my blog now for a couple of days, and analytics have started to show on my (free) Cloudflare account. It’s quite interesting to see that over 50% of my traffic and hits have been cached through Cloudflare.

Although I have not enabled aggressive threat-controls, Cloudflare does seem to catch many of the threats. It just a pity that at the moment not much reporting is available (I suppose this might be different in the Pro version):

Cloudflare threat control

The combination of Cloudflare with Amazon S3 and Amazon Cloudfront (a topic which I will cover in an upcoming post) is a huge improvement to absorb traffic spikes and improve page-speed.

Comment below on your speed experience on my blog (where you from would help), but you should notice a considerable improvement in image- and page-load times.



VN:F [1.9.13_1145]
Rating: 2.0/10 (1 vote cast)
VN:F [1.9.13_1145]
Rating: 0 (from 0 votes)

WordPress and CloudFlare

If you have decided to use W3 Total Cache as your caching mechanism, the next logical step is to use CloudFlare as an accelerator.

CloudFlare - Website Performance

Think of CloudFlare as your website accelerator (in simple terms it’s a distributed hosted nginx server). Enabling CloudFlare (the basic plan is free) on your WordPress installation with W3 Total Cache is really simple:

  1. Go to W3 Total Cache’s General Settings and click on the CloudFlare signup link.
  2. Signup with the Free CloudFlare plan
  3. Review your CloudFlare zone file (you will probably not have to change anything)
  4. Change your blog’s domain name-server records
  5. Configure W3 Total Cache to use CloudFlare by configuring your API key and security settings.
I noticed a dramatic speed improvement with CloudFlare compared to just running W3 Total Cache.

 

Warning: Since CloudFlare acts as a caching proxy server, any subsequent theme or plugin changes will take some time to replicate. The easiest way to force a refresh is to obviously minify your files in W3 Total Cache and then changing your CloudFlare settings at CloudFlare to development. This will bypass the caching proxy for four hours, avoiding any style-sheet or JS issues.

VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.13_1145]
Rating: 0 (from 0 votes)

WordPress plugin – W3 Total Cache

Once your WordPress installation is up and running and you are satisfied with the plugins and themes you have installed, it’s time to optimize your installation for performance.

I would leave this task as the last step in any blog-installation, as caching can break themes or plugins and it is much easier to get your blog up and running and then tweak the installation afterwards.

Optimize WordPress with W3 Total Cache

Amongst all the various plugins I reviewed, W3 Total Cache improves the user experience of your site by improving your server performance, caching every aspect of your site, reducing the download times and providing transparent content delivery network (CDN) integration.

W3 Total cache gives you:

  • At least 10x improvement in overall site performance (Grade A in YSlow or significant Google Page Speed improvements) when fully configured
  • Improved conversion rates and “site performance” which affect your site’s rank on Google.com
  • “Instant” subsequent page views: browser caching
  • Optimized progressive render: pages start rendering quickly
  • Reduced page load time: increased visitor time on site; visitors view more pages
  • Improved web server performance; sustain high traffic periods
  • Up to 80% bandwidth savings via minify and HTTP compression of HTML, CSS, JavaScript and feeds
Installation and configuration can be overwhelming and your success depends on your hosting provider. Although W3 Total Cache offers a number of accelerators – disk based, eAccelerator, Opcode caching, there is a good chance that those caching mechanisms are not offered out-of-the-box by your hosting provider (especially in a shared hosting environment).
I chose a virtual server hosting plan with eApps.com, which comes with unlimited databases, custom PHP configurations, mail, DNS and a variety of other options and had little problem installing extra packages to support W3 Total Cache fully.
Continue reading “WordPress plugin — W3 Total Cache” »
VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.13_1145]
Rating: 0 (from 0 votes)

WordPress plugin – WPTouch Pro – turn your blog into an iOS app

Once you have designed a website, you will be faced with the challenge to “mobilize” your content. While RSS feeds allow you to provide content on a mobile device, there is nothing better than an almost true mobile experience.

WPtouch and WPtouch Pro come to the rescue in the form of a WordPress plugin which provides automatic device detection and renders your WordPress content on iPhone, iPad, Blackberry and Android devices. The look and feel as depicted below on iPad (left) and iPhone (right) provide an almost native look & feel on the device.

WPTouch - turn your WordPress blog into a mobile application for iPad  WPTouch - turn your WordPress blog into a mobile application for iPhone

All content (text and images) is reformatted and resized on the fly and there is no need to zoom in and out to view your content properly on the mobile device.

WPTouch also handles media seamlessly on the supported devices and re-renders where necessary. Theming of the application is extensive and for supported devices, you are able to place an icon as a “home-page bookmark” onto the device.

The plugin integrates properly with most other plugins (such as Disqus) and provides warnings and workarounds for compatibility issues (i.e. with W3 Total Cache you have to exclude certain user agents from caching).

Installation and configuration took a mere 10 minutes until my blog rendered properly on iOS and Android devices.

VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.13_1145]
Rating: 0 (from 0 votes)

WordPress plugin – 404 Redirected

Anyone migrating from b2evolution or any other blogging software which does not fully support importing into WordPress will feel a world of pain to get the original blog’s content right. If you don’t pay attention, you will receive many 404′s as the generic importers (or even the old b2evolution importer) will import with wrong permalinks (i.e. in my case 80% of my posts had the wrong date-slug).

While Google Webmaster toolkit came to the rescue in restoring the correct slugs and forced me to manually updating posts and Permalinks, in hindsight this was completely unnecessary, as 404 Redirected would have done most of the work for me.

The plugin provides “Automatic Redirects” which will match the inbound Permalink to the existing articles through a 301 redirect and fixes almost all issues.

The biggest problem I encountered after the import was that the tag-format changes in WordPress (b2evolution uses “/ps3:” whereas WordPress uses “/tag/ps3″) which results in many errors.

The 404 Redirected plugin captures all 404′s and you can view them via the “Captured 404 URLs” tab. The awesome feature is, that any 404 URL can then be manually mapped to a post, a tag or a category:

Wordpress Plugin 404 redirected - manual redirects

Within a few days I managed to resolve most of the 404 errors and every once in a while some additional 404′s for tags and categories require re-mapping which is a really painless exercise nowadays.

VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.13_1145]
Rating: 0 (from 0 votes)

Just smush.it – blog image optimisation

Finally my migration from b2evolution to WordPress is complete and the transition was overly painful, as there was no direct importer available. Many 404′s (which I manually monitor with the WordPress plugin ’404 Redirect’) caused quite a lot of trouble.

After hardening the installation and tuning Apache, MySQL as well as WordPress, the final step was optimizing the old images.

If you have access to Java on your server, download the Java smush.it application and then run it on your server:

java -jar ~/smushit/smushit.jar -imageDir=[path-to-images] -verbose=true -dryRun=false -imgExtensions=gif,png,jpeg

The above will optimize all images recursively and resulted in a 35% reduction in image size. Install the WP Smush.it plugin afterwards which optimizes newly updated images as well as allows you to bulk-smush existing images.

VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.13_1145]
Rating: 0 (from 0 votes)

Performance-101: www.liveads.co.za

At bidorbuy we have worked very hard to optimise website-performance to achieve a relatively good user-experience. We believe that with good performance comes lots of link-love from Google and sofar we have seen this pay off.

I am always interested in looking out for possible competition, and just noticed today, that Vodacom launched a half-baked classifieds website over at Liveads.co.za. I used to consult for Vodacom in the past and found it rather embarrassing as the website looks like the Wayback Machine came and visited.

It does take a lot to put a website together and score an “F” like Juju:

More so, it takes a lot of disregard and effort to make it to all “F”s, but it is not just the look and feel, but also the performance characteristics of the site:

  • It takes 18 seconds to download the homepage which only starts rendering after 11 seconds. On a primed cache it still takes 14 seconds for the page to load which only starts rendering after 8 seconds. This is already bad as Google deems any site rendering above 3,5 seconds as slow.
  • Your momma is so fat: I hope not, but the home-page is. Weighing in at a proud 604KB. Even with a primed cache all 30 images displayed are uncached and result in 159KB of data every time. (Perhaps a clever ploy to get extra money from 3G subscribers?)
  • Not sure how LiveAds managed to do it, but even a primed cache results in a dreadful long load time — not to worry, overpaid consultants at Vodies, I provide you a solution for free in the bullets below.
  • Turn on compression: This is in the webmasters for dummy, takes about 2 minutes to configure and provides sensational results.
  • Cache control: How on earth did you manage to de-configure your server that none of your 63 resources referenced on your homepage has any expiry, last-modified or cache-control settings?
  • Javascript kiddies at work: 14 Javascript files referenced, inline jQuery code and some weird Google-tracking code. Minify your JS, include only what is necessary and Google Async Tracking is your friend.
  • Deferred loading: All those pretty 14 Javscript files also block all other resources from loading. This costs you over 8-10 seconds as the browser is not able to render the remainder of the page. Combine those 14 JS into one file and place it at the bottom of the body or defer loading altogether.
  • ETags: Don’t use ETags with a default install of your webserver. ETags consist of the inode which is a unique file-descriptor and this will result in your ETag always to be different in a load-balanced environment. Use proper expiry/last-modified rules and cache-controls instead.
  • Amazon cloud: So you use Amazon CDN for image storage and even managed to get no expiry/cache-control on those – how did you make this happen?
  • Sloppy site images: Your Grid-images are cute, but if you had applied proper JPEG compression, you would have reduced both images from 80KB per image down to 20KB – quite a difference in load-time (considering that those are not even cached)
  • KeepAlive: Your web-server has none. Your sysadmin should know about persistent connections. You site will not scale and ever perform with basics lacking.
  • Local is Lekker: Yes, we live in a global village, but serving the site out of Egypt to your local users is just strange. Big data-center with own ISP-services and off-shore hosting? Vote of confidence right here. A DNS lookup exceeds 500ms (should be below 100ms) and it takes on avg 200ms to just establish a connection to those individual resources (14 Javascript * 200ms connect time = 2,8 seconds / download-time for a 42KB-resource = 1,4 seconds).
  • Redirects: Why oh why do you have to do a redirect from your home-page to “/en/home” – this is a client-side redirect and costs me another 500ms?

The above should be a lesson to any corporate on how to build websites. I fear that the very same people will also advise on SEO (you do realise that your site has absolutely no SEO value) and it will be interesting to see how long this site will be around. My Internet-death prediction: 2 months (but not without spending lots of more money to beat that dead horse).

To avoid repeats like this: YSlow, Google PageSpeed, Firebug and HTML Validator should be standards tools for any project and no website should go live without good ratings.

Try a visual comparison via which.loadsfaster.com

VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.13_1145]
Rating: 0 (from 0 votes)