How to improve server response times

Written by
Published on

Performance and optimization are important for generating a good user experience on any website. Aside from ensuring that you have properly sized images on your server, there are many other things that can impact your websites overall speed and initial loading times.

If you ran a Google PageSpeed Insights audit on your website, then you might have received the message informing you that you should 'improve your server response time'. I know that I have. And I've worked hard to ensure the best possible performance that I can get out of my server.

Here is a list of things that you should take a look at in order to improve your overall TTFB (Time to first-byte).

Optimize your database

Often than not the root cause of your speed issues lies at the very source of the content on your website, and that is the database. Before your code can even begin to render any kind of HTML or CSS, it usually first needs to connect to a database on a server somewhere near your hosted site in order to run a query, wait to retrieve the data and then process the data accordingly.

You might think that aside from writing better queries there isn't much else that you can do to a database in order to improve performance.

select * from blogs

That is one important element, for sure. And you should absolutely focus on writing better queries, particularly when working with databases that are large and complex. But there's alot more that you should take into account. A few of those things include:

Properly indexing tables - Depending on your RDBMS (Relational Database Management System), you might need to ensure that indexes are properly created and managed for all tables and relations. Indexes are essentially like the index in the back of a book. They help to locate specific records much faster than doing a sequential one to one look-up.

Before anything else, this should be the first thing that you focus on.

Reducing joins - In a relational database, tables are connected through what are known as joins. Essentially, a record in a specific table can have a relation with another record in another table. Think of a user on a website that can leave a comment. Each comment that the user leaves behind is tied to that user alone.

Joins can be expensive however, from a resource management perspective. It's typically best to only join tables if you are indeed going to be needing multiple columns from each table. If you are joining just to retrieve a single record from a joined table, using a subquery might be a better choice.

Selecting specific columns - The most common type of database query that you will find relies on using the catch-all asterisk (*) in order to retrieve every column from a given table.

select * from blog

And that's because depending on your table columns, you could end up with long difficult to read and edit queries such as the following:

select id, title, content, datepublished, authorid from blog

The (*) makes short work of that. The problem is that not every column is a single value number or string. Some columns, such as the contents of a blog for example, are very large strings. And if you are not using that column, you still have to wait for the database to return that data back to the server.

The trick lies somewhere in between. You can still use the (*) selector for smaller database tables where the overall data size is negligible.

Enable server-side caching

What is caching you may ask? Caching is one of the quickest ways to improve performance on any website. Essentially, a caching engine can render your webpage virtually and store the final source in memory (typically in RAM) for quicker retrieval. When a user then subsequently visits your webpage, if the page in question is already in cache, the user will be served the source that is already rendered without having to go through the application workflow.

While caching can typically offer improved overall performance, it does not come without a few side effects.

For one, caching requires memory. As mentioned above, that memory is typically RAM, but not always. If you are hosted on high-performance SSD drives, then storing cached files in ROM can be equally as optimal. In this case, caching will come down to 2 things. How many resources your server has and how many pages you are keeping in cache at any one time.

If you have 20 web pages, then you are fine. Caching probably won't improve your overall performance in any meaningful way. If you have 20,000 pages, then caching will require substantially more resources.

Another potential issue that you will probably face has to do with the fact that you don't always want cached files. Content is dynamic on the web these days. Users click on 'like' buttons and comments get added by the hour. These are things that typically you don't want cached in any way.

Your options in order to bypass this issue are essentially to load any dynamic content through JavaScript using AJAX. In this way, the JavaScript code itself can remain cached, however the data will be pulled continuously on every page load.

As with everything else, your specific implementation will depend on your programming language, framework and operating system.

Upgrade your server

Sometimes, the main reason why your speed and performance isn't up to par is simply because your server just can't handle the load. This is particularly true if you are using a shared server in which dozens or even hundreds of websites are being served by the same hardware.

This will mainly depend on your hosting provider however. Some hosting providers take performance more seriously than others. SiteGround for example has upgraded all of their servers regardless of pricing tier to include SSD drives offering much more stable and optimal performance across the board.

But if you are seeing heavy traffic numbers on a daily basis, then switching over to a VPS (Virtual Private Server) might make more sense. In this way, you get a dedicated cluster of resources to use as you wish without having to share resources with other applications. These servers typically come with a heftier monthly price tag however. And much of the configuration on the server will have to be done by you.

Remove unused code

I can assure you that any web application older than 4 years has a substantial amount of unused code. I know because every professional project that I have personally worked on has had this. And my own projects, such as this blog, have it too.

When running a live website with hundreds of pages, thousands of visitors and constantly changing business plans, the code is in flux on an almost daily basis. Features are being tested, added and removed constantly. As such, things are missed many times.

It's a good practice to take at least one day out of the week in order perform a code review on your own work. I myself do this on the weekends before the workweek begins. And I almost always find something that can be removed without causing any issues whatsoever on the website.

It might seem like trivial code sometimes that gets left behind. A few functions here or a helper method there. But if left unchecked, it will inevitably catch up and eat away at your overall performance.

In general, improving server response time is not a trivial or easy task. It might require more careful attention to the code, or a more expensive server per month or even heavy configuration on the database and server. But that's really what a web developer is suppose to be doing when not churning away code. They are suppose to maintain the codebase to ensure optimal performance and a good user experience for everyone.

Comments

No messages posted yet

Developer Poll

Q:

Add a comment

Send me your weekly newsletter filled with awesome ideas
Post