We are the Website Speed Experts!

01274 985905


Case Study: A Rebuild of Techniconica.com

133 Views
Posted on May 24th, 2015 by

History

We recently rebuilt one of our websites in a bid to gain additional speed, namely Techniconica.com. The old site was built with WordPress and although much work was done to optimise the website’s frontend such as enabling HTTP compression, caching DB requests and other tricks to speed up the website, we were unable to reduce the time to first byte (TTFB) to below 0.8 seconds, even if the page itself was as snappy as we could make it when it actually downloaded.

Before and after of the Techniconica.com rebuild.

Why Rebuild?

We originally wanted to shave off the time to first byte and we tried numerous different options to shave off those precious milliseconds, all to no available as we couldn’t break the 0.8 second TTFB due to the fact we were using several custom post types and several plugins which were required for the site’s functionality.

The only answer without resorting to hacking WordPress up and removing whatever we didn’t need from the core of WordPress was to build our own CMS, albeit with a stripped down admin interface  – something that certainly helped us when we were putting the website together initially has now become something of an unnecessary evil as the posts themselves are, largely, just plain HTML anyway.

Before & After – The Results!

Before

http://www.webpagetest.org/result/150506_34_15D8/1/details/

  • Load time: 3.571s
  • First Byte: 0.776s
  • Start Render: 1.393s

After

http://www.webpagetest.org/result/150524_SM_FQJ/1/details/

  • Load time: 2.171s
  • First Byte: 0.511s
  • Start Render: 0.795s

The Custom CMS Features

As with any re-build, we had a set of initial goals we wanted to meet:

  • Be much faster than the original website – we were and still are aiming for a realistic goal of 0.5 second TTFB.
  • Minimise the impact on our DB – WordPress uses about 27+ queries to load the home page (http://wordpress.stackexchange.com/questions/154892/how-many-wordpress-sql-queries-per-page). We also had a Simple Machine Forum acting as our user account system which added more queries (which is one of the reasons why WordPress had such a high TTFB on our website we think).
  • Improve on the old website – whilst we were recreating the website, we looked at ways to improve on what we had previously without losing anything in terms of visual looks or functionality.
  • Improve the website speed in other areas – we were also able to implement a number of strategies to improve the source code of the website, such as doing optimisations that were impractical to do with the WordPress website (such as “page fragment” caching, A/B split testing & static content page level caching).
  • Audit the website URL structure – due to the way the old website was structured within WordPress, we had a few quirks we had with the old website. For example, we had all the universe articles under /universe-articles/. We moved all the content over to simply /universe/ when the new website launched, allowing us to keep the url’s shorter and therefore cleaner. We also made sure to set up 301 redirects from the old to the new as part of the website built as we moved sections around.

The CMS Architecture Features

  • The CMS itself is relatively lightweight, using only 6 to 12 queries to render any given page (including 3 to run the site’s cart functionality).
  • The content itself is stored as a set of PHP files (half of which are static files with no dynamic elements at all).
  • 95% of the database queries are cached using Memcache to further reduce latency.
  • We save pre-generated HTML chunks as “page fragments” within the CMS itself – which are saved both to disc and to Memcache. These are typically used on dynamic pages where the page is rarely updated, but frequently read from. We can create page fragments at the page level, or simply save and recall individual fragments of HTML.
  • We have inbuilt tools to create minified JS & CSS within the CMS admin features itself.
  • Be flexible and easy to extend and modify as the site grows and new features get developed

The Way It Was Built

We didn’t want to run with a pre-designed framework and instead invented our own, simpler solution – we did this due to the increased overhead that frameworks bring. Even the best designed frameworks have some inherent overhead which comes with their flexibility.

The CMS we built was designed to be small, lightweight and flexible enough for our needs. We have a core, single template which we can toggle particular parts of the page dynamically on a page per page basis.

Database

We abandoned the old database structure for WordPress as we found it to be a little inflexible for our new CMS.

We had to create some tools to port over the data from the old DB to the new one into the new database, and these tools were unique to our new DB structure.

Caches

We also cache “page fragments” using MemCache – these are unique to various pages and are dynamically generated the first time a user visits and then cached on subsequent visits, saving valuable time and energy.

Database caching is built into our custom MySQL database wrappers – SELECT’s are cached by memcached automatically when they are ran.

We also cache everything to disk, including DB queries and page fragments. This slower cache acts as a persistent backup cache and our cache wrapper functions also manage the disk cache when we purge elements from the MemCache.

The Simple Machine Forums

We had to keep the Simple Machine Forum database tables as re-structuring and re-working those tables weren’t part of the rebuild.

We were also happy with the performance of the forum itself so further work on that wasn’t really done aside from several small, front-end optimisations such as image optimisation and enabling HTTP compression for static assets.

Performance Monitoring

We also added functionality to monitor the website’s performance as well as data collection to allow us to improve the performance further down the road, once we’ve collected enough information about our “real world” usage.

We collect data because our own development machines aren’t the best representation of the final system’s characteristics and we need data to set goals and objectives for future speed improvements and be able to measure the success (or failure).

In Summary

The CMS rebuild itself was a success – we got a faster, more responsive website which is also flexible enough to give us future growth and expansion.

Like our articles? Like us on Facebook or Tweet about us to spread the word!
About the Author
Stephen Bailey has a passion for making websites fast and believes that the web should be faster for everyone. He is a freelance web designer & developer of 5 years experience in the trade and has helped to run and build several online communities and helped them grow and flourish.
Visit Stephen Bailey's Google+ page.


Comments

There are no comments currently for this post!

Leave a Reply

Your email address will not be published. Required fields are marked *