Website performance is an important part of your overall website design. For example, Drupal, a highly sophisticated and reliable CMS, makes almost 700 MySQL queries per page request. Depending on your installation this can be detrimental. If you are on a shared hosting platform your database instance will always be on a different host (and although it will be “localhost” each connection will cost you lots of time). So when picking Drupal you need be aware of how you final architecture will look like. In the next few paragraphs we will go through several steps to improve your website starting from our server side PHP code.
Improving server side PHP code
PHP has a very useful extension called ‘XDebug’. If you are running WAMP this is already installed – but if you haven’t installation is easy. All you need to do is add the extension .so (UNIX) or .dll (Windows) file to your php.ini file. You can find out more about this at XDebug’s website. Once you include it in your bootstrap script you will be able to understand how much time is consumed by each individual task that your script is doing. Below is a picture of the profile of an app I wrote. In this case we put the database on Amazon and allowed different people to maintain their own implementations.
As you can see a bulk of the time (total time for execution was just over 22 seconds) was spent on the 700+ database queries. This was slowing down the app performance, and it was seen that down the road if the total data requested was more this could easily go up and slow down performance even more. Armed with this information we looked at the script and re-wrote it, drastically reducing the amount of database queries from 700+ to a static 3 (even if the data grows, the queries will only be 3). We then put the data together on the server before pushing it to the client. It is not that the database server was slow, but each new query require a network transmission from the Apache PHP server to the MySQL server. This network travel of information is what slowed down the script. Re-writing the script we ended up with an execution time of 0.6 seconds – which is 98% improvement.
This is just an example of what you can do once you get a profile from XDebug – it will allow you to find the bottleneck in your script so that you can address it directly.
More on Network Connections
For better or for worse, the network connections is what slows down website loading. A browser will only load two files from the same web address at a time (similar to your ftp client). Does this means you can achieve simultaneous loading by distributing your files on different web addresses? Yes, and no. It is true that with 4 files distributed evenly over 2 addresses you could have them load simultaneously, but each address requires a look up and a way of your browser establishing a path to the file. What do I recommend:
- Write a script that combines and mimifies your CSS and Javascript (in the proper order that you would want the CSS or Javascript loaded). One of the biggest problems of WordPress is that with 20 plugins you end up loading 20 additional CSS files and possibly 20 or more additional Javascript files. From a maintenance perspective it would be foolish to combine all the scripts and styles and then edit huge files. It is good that files are kept separated. So either at run time, or at deployment, it would be beneficial to combine all script and style files into a single file and load that file.
- Use CDN (Content Delivery Networks) to reduce the number of hops that are required between your viewer and your server. This will drastically reduce overall webpage load times. A CDN keeps copies of your files at locations that are possibly closer to your intended audience. For example, your host might have their servers in Texas and your primary clients may be accessing your website from Toronto and Vancouver. By using a CDN you will be able to keep your data on servers that are close to Vancouver and Toronto respectively – thereby reducing the travel time per data packet, and the overall website load time.
- Make sure that your Facebook “Like” domain matches the domain that you provided in the Facebook App. If your domain doesn’t match Facebook takes a long time to respond.
- While we all like Google Fonts, you can use our own, and include them in your CSS file – thereby saving you one more network connection.
