Who’s to Blame for Your Website’s Poor Performance?
Is my website’s performance up to par, and if not, who’s responsible? Let’s delve into how we can systematically answer this question in this post.
If your business relies on conversions, leads, or actions obtained through your website, and especially if you’re not technically inclined, you’re likely concerned about whether your website’s technical performance is up to par. So, how can you get reliable information on this topic?
When you start to investigate this issue, you’ll first encounter some online performance tests available on the internet. Upon conducting these tests, you’ll find that they often provide seemingly unrelated feedback. While one test might indicate excellent performance, another could describe your situation as dire. Although most of these tests are accurate, the problem lies in their differing focus areas. So, we’re back to our initial question: “Is my website’s performance good enough, and if not, who’s responsible for that?” Let’s discuss how we can systematically find an answer.
First, let’s start by identifying and understanding the usual suspects. The first one is the server your website operates on, which could be a shared hosting, a virtual server, or a physical server. The server’s job is to execute the code of your website’s software, delivering results in a browser-readable format based on visitors’ requests. How quickly the server responses, its connection speed and bandwidth, and its proximity to the requesting visitor will directly affect your website’s performance.
But that’s not our only suspect. The second candidate is your website’s backend code. No matter how good the server performance is, the tasks executed by your code and the time they take are crucial. For instance, if your website with a million pages uses a code that checks each page one by one to find the requested page, there’s not much the server can do. However, distinguishing whether the issue lies with the server or the code isn’t straightforward, as poor code can degrade server performance, just as a bad server can extend the processing time of your code. We’ll discuss how to differentiate between these later in the article.
The third potential problem point is the browser, i.e., the visitor’s computer. Although at first, it might seem beyond your control, remember that your server and backend sends the code to the browser displays to display. Managing how heavy your website’s expectations from the browser is also your responsibility. Thus, how many different resources the browser needs to communicate with after receiving your code is also under your control.
While there could be potentially a few more candidates to here, for an average website, over 95% of the issues will stem from these three. To keep this article as simple as possible, we’ll skip the others for now. Let’s delve in each one now.
Server Performance
Having lined up our suspects, it’s time to find the culprit. Let’s start from the moment a visitor types your website’s address into their browser. The visitor’s computer needs to connect and communicate with your server first. At this point, a critical metric to monitor is TTFB (Time to First Byte). TTFB measures the time from when the visitor’s request is sent to the server to when the server’s first response reaches the visitor. This duration includes both the time to establish the connection and the time the server takes to process the request. Since we’re focusing on server performance, we need to minimize the impact of our code on this duration. We can do this by measuring the TTFB of static files on our web server. The TTFB value of simple .html or .css files, which are served directly without being processed by the server, will give us a good idea of the server’s response time.
What should the TTFB value be, and what constitutes good or bad durations? If you’re using shared hosting, times between 400ms-600ms can be considered acceptable. On a strong server close to your visitors, you might aim for around 200ms. You’ll pass Google PageSpeed’s test up to 800ms. However, TTFB values above 1 second could indicate a problem with your server’s response time.
How to Reduce TTFB
TTFB is a relatively consistent metric, so the formula and steps for improvement are quite clear:
- Upgrade to a Higher Performance Server and Use a CDN: Reducing the load on your server or increasing its capacity can improve this time. Using a CDN can help reduce the load on your server by serving your files from the closest location to your visitors, which can be beneficial for your TTFB.
- Host Your Website Closer to the Majority of Your Visitors: Even in a perfect world, you can’t transmit data faster than the speed of light. If the computer responding to your visitors is on the opposite side of the world, it will lead to longer waiting times. Of course, you might have visitors from all over the world, but choosing your server location based on where most of your visitors are can reduce average response times.
- Use of Caching: Preventing your server from doing the same job repeatedly for the same requests by storing standard responses can help reduce both the workload and the TTFB.
Discover the hidden truths behind SEO that can transform your website’s performance.
In this blog post, we’ll dive into the world of web hosting. Understanding your options and knowing how to choose the right type of hosting for your website are crucial steps in managing a successful online presence.
Explore the comprehensive features of the Observer Dashboard in our latest blog post. Learn how to monitor your website’s uptime, performance, domain details, and much more to enhance site efficiency and user experience. Sign up for Observer today to start optimizing your online presence.
Select free plan to meet or have a powerful assistant that includes all our features.
