Google Page Speed Basics

#2 30th May 2013    Trevor    Jamie    Google Page Speed Basics


Useful System Development Tools

  • Google page speed add on
  • Google Chrome or Firefox

Further Info / Support

If you have further questions, suggestions or Zend Server
enquiries please contact Chittak via:
01202 611 711,,

As web developers, it’s one of our goals to make web pages load as quickly as possible. There are many reasons why we want to do this; here are some of them…

  • Bounce Rate reduction: customers will leave a slow website and may move on to a competitor’s site
  • To increase the conversion rate
  • To maximise onsite SEO benefits with search engines, as they prefer fast websites
  • To minimise web server load, allowing your web server to handle more visitors

One of the primary tools we use for this purpose is Google PageSpeed. The link below will let you use the insight services:

Across various internet usage studies*, the overall results are quite consistent as follows:

  • About one-third of website visitors will abandon a website that hasn’t loaded in five seconds; some won’t even wait that long
  • When visitors encounter a slow website, between up to 50% of them will not use the website again
  • Around 25% of visitors actively go to a competitor’s website to complete their purchase
  • Mobile website visitors are slightly more willing to wait initially but quickly drop off if the page takes six or more seconds to load

* Main reference (

The screenshot below is of the Web Design page that we have designed and developed with ‘Start Your Own Business’. You can see it received a Google PageSpeed score of 87/100. Depending on the number of visitors using the web server when running the tests, these results can vary by 1 or 2 points but the score gives you a very good idea of overall performance.

As you can see above Google checks a large number of factors when it examines your web page. Ideally, you need to achieve green ticks, but even green ticks can contain items that need improving.

Here are some very common issues:

  • Images without their dimensions set (this takes the browser longer to render the page)
  • Images that need resizing for display (e.g. the page uses a 100x100 pixel image for a 50x50 pixel space, this means the browser has to spend time scaling the picture)
  • Uncompressed JavaScript (minifying the JavaScript resources is more efficient as it reduces their size)

To read more about our work with Start Your Own Business, click here to see the case study…


To find out more information, see the extended article here…


Extended Information

Needs more speed?

So by now you’ll have made some speed gains by using Google PageSpeed to highlight areas of improvement with html, optimise image dimensions and file sizes and you might have gone as far as changing some JavaScript (e.g. JQuery) to be called via a Content Delivery Network (CDN), which is all good but it will reach a natural limit in its improvements.

To make further enhancements at this point, access and control of the server becomes more important in order to carry out the following:

  • .htaccess advanced settings
  • PHP Web server Installation setup and configuration
  • Database Performance
  • Hardware Specification

.htaccess settings in detail

Hopefully you will have returning visitors on your website. It’s fair to assume that you could improve those return visits by making sure that the expiry headers are being sent to their browsers and that the expiry values are set to a suitable length of time. This results in the page loading quicker because the browser is forced to keep a copy of files delivered in the page render, so upon the next render each user’s browser already has access to the files; it doesn’t have to wait for them to download again.

How To: In the htaccess file you can set the cache instructions for file types, assuming that the mod_expires module is enabled in Apache, then we can set rules based on file as in the example below ->

Here we specify the file type, the type of condition and the length of time that the file should be cached for.

            # Cache Control with .htaccess EXPIRES BY TYPE
            # from
            ### turn on the Expires engine
            ExpiresActive On     
            ### expires after a month in the client's cache
            ExpiresByType image/gif A604800
            ExpiresByType image/icon A604800
            ExpiresByType image/png A604800
            ExpiresByType image/jpg A604800
            ExpiresByType image/x-icon A2592000
            ExpiresByType application/pdf A2592000
            ExpiresByType application/x-javascript A2592000
            ExpiresByType text/plain A2592000     
            ### expires after 4.8 hours
            ExpiresByType text/css A17200     
            # Please note that the "A" before the numbers above stands for Access.
            # This means that the stopwatch starts when a client accesses the file.
            # You can also use "M" for modified.     
            # TIME CHEAT SHEET
            # 300 5 MIN
            # 600 10 MIN
            # 900 15 MIN
            # 1800 30 MIN
            # 2700 45 MIN
            # Hours
            # 3600 1 HR
            # 7200 2 HR
            # 10800 3 HR
            # 14400 4 HR
            # 18000 5 HR
            # 36000 10 HR
            # 39600 11 HR
            # 43200 12 HR
            # 46800 13 HR
            # 50400 14 HR
            # 54000 15 HR
            # 86400 24 HR
            # Days
            # 86400 1 DAY
            # 172800 2 DAY
            # 259200 3 DAY
            # 345600 4 DAY
            # 432000 5 DAY
            # 518400 6 DAY
            # 604800 7 DAY
            # Weeks
            # 604800 1 WEEK
            # 1209600 2 WEEK
            # 1814400 3 WEEK
            # 2419200 4 WEEK
            # Months
            # 2419200 1 MONTH (FEBRUARY)
            # 2505600 1 MONTH (FEBRUARY LEAP YEAR)
            # 2592000 1 MONTH (APRIL, JUNE, SEPTEMBER, NOVEMBER)
            # 31536000 12 MONTH

PHP Web server setup

This area of improvement is specialised and requires Zend Server to be installed on your Web Hosting, which is an area where we can help. When it has been installed (it is compatible with Apache and IIS web servers on Windows, Mac, Linux and IBM OS platforms), we make sure that you only have the required PHP modules installed, so PHP itself runs as lean and fast as is possible.

Then we setup a Zend Server-side page cache for individual pages based on simple and complex conditions, which is particularly useful for intensive PHP systems such as Magento where you can set up a page cache based on rules using the parameters passed. This means you can have an un-cached version for logged-out visitors and a cached version of the same product page for logged-in website visitors should you desire.

Worried about the PHP cache lasting too long?

Not a problem, the cache can be permanent or time-limited, so if you have a rapidly changing blog you could set a time limit of 15 minutes. Also the cache itself is so clever that, if needed, you can actually call Zend Server from the PHP code to destroy the current cache and create a new cache based on some other event occurring in the wider PHP system.

If you don’t have Zend Server but want to find out more, please call us on +44 (0) 1202 611 711 or email

Database Performance

Database optimisation is a huge topic all on its own, so I’m just going to talk about one particular area which is platform independent. Whether you are using Microsoft SQL Server, MySQL, Oracle, Postgress or any other major RDMS (Relational Database Management System), platform one performance has always delivered speed improvements on systems we’ve worked on.

That is Database views, a database in simple terms gives a fixed view of a database table or set of tables and the main speed gain comes from the fact that the database platform is therefore able to store the initial overhead of the transaction as it isn’t going to change between requests.

Below is a basic sample test I carried out on a MySQL database table with 19k records in it.


SELECT * FROM customers;


/* Affected rows: 0 Found rows: 19,981 Warnings: 0 Duration for 1 query: 0.234 sec. */


SELECT * FROM v_customer;


/* Affected rows: 0 Found rows: 19,981 Warnings: 0 Duration for 1 query: 0.124 sec. */

So even in this limited example of a query that was being asked during the creation of a page in an e-commerce system I was able to save 0.110 seconds in the time to create that page.

Is 0.110 seconds worth it?

Well, at first glance that may not sound that impressive to you, but in this case that’s almost a 50% reduction. Now that sounds better, right?

Next, let’s remember that this saving was over just a single request, so imagine what happens when we ramp up the numbers.

This all means that each user’s experience will be better and that technically due to this change, your server now has a higher throughput capacity without any hardware level improvements!

Hardware Specification

Just like database performance, this is a massive area to cover. The first question I’d pose to you is do you actually know the level of utilisation of your server?

Usually the answer is either no, or possibly it might be that someone connects to the server to try and monitor the CPU usage level. Neither response is particularly great. One of the many added benefits of running Zend Server on the system setup is that it provides in depth reporting on the actual web server utilisation (see images below).

This can be for different time periods: the examples I’ve created are for 1 day and 1 month, the possible reports are from ‘1 hour’ to ‘1 year’ and even to ‘all time ever’ that the server has been running.

This is key as often it is tempting to accuse the web server of being “a bit slow” without any proper evidence. So if we increase the CPU specification, then everyone (the staff) has a placebo effect for a while as they get told the server has more power, so there’s a temporary positive vibe that the website will occur until people realise that the performance hasn’t improved and actually the improvement may be down to visitors leaving the website and visiting a faster competitor’s website! That may sound cynical, but it does happen.

So the graphs above show, in the case of one of our test servers, that the CPU usage is low and that the memory usage is high but acceptable. If the user experience became slow based on the profile expanding in the same manner, the correct step to boost performance would actually be to increase the specification of the RAM used, as the CPU is not presently the bottleneck in the system.

I hope you’ve found all the information above useful or at least informative. Please contact us for advice, assistance or with suggestions for articles you’d like us to write on topics that you feel need explaining.


Update: As of May 14, 2015 the very useful Firefox and Chrome module version appears to have be discontinued by Google. See here for more info.


Further Info / Support

If you have further questions, suggestions or Zend Server enquiries please contact Chittak via:
01202 611 711,,

Thanks for reading!
The team at Chittak