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:

  1. 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.
  2. 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.
  3. 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.

Backend Code Performance

Now let’s examine our backend code performance. The first sign of a problem in your code might be a significant difference in the TTFB between our static and dynamic pages. Of course, the time required for the backend code to execute can vary greatly from page to page, significantly affected by the total traffic your web server responds to and the size of the data it operates on. Thus, someone trying to explain your website’s poor performance could have dozens of excuses.

However, without getting lost in excuses, I can simplify the issue for you: if your backend code can’t complete its tasks in milliseconds, you have a structural problem. If the current code’s execution time can’t be improved, there’s likely a fundamental architectural issue.

If you’re facing performance issues with your backend code and struggling to improve it with your current technical team, I highly recommend seeking a second opinion from a competent individual or team.

Frontend Performance

Your backend code has now finished its job, and the codes for displaying your site are sent to the user’s browser. But our work isn’t done yet. In fact, the most complicated part starts now. Let’s now look at potential problems in displaying the site interface and how to solve them.

When a visitor attempts to open a page, we first send them the html code of our page as plain text. This document describes to the browser how to display our page. However, our resources aren’t limited to this document. The addresses of many other files contained in our page, such as images, style, script, and font files, are all included in this initial document. After the browser receives and reads the first document, it begins loading the other resources in sequence.

Here, we’ll discuss two critical metrics that measure the stages of page loading and provide significant clues for identifying problems.

FCP (First Contentful Paint)

FCP measures the time it takes for the first visual content to appear in the browser as your page loads. From this point forward, we’ll add all subsequent durations on top of the FCP phase, including the time waited during the TTFB stage.

The critical aspect for FCP is the external resources that must be loaded before the page can display (Render-Blocking Resources). For example, does your page need to wait for font files to load before it can display, or have you arranged them to load optionally as they become available? The primary goal of FCP is to ensure visitors start seeing content as quickly as possible.

According to Google’s guidelines, the FCP phase should complete within a maximum of 1.8 seconds. Anything over 3 seconds is considered “poor performance.”

If your FCP time seems problematic, try reducing the number of files that must be loaded upfront. Also, minimizing both the number of resources and their locations can be beneficial. Implementing lazy-loading for images to load them after the page has initially displayed can also be an efficient choice.

LCP (Largest Contentful Paint)

The second phase is LCP, which measures the time until the main content on your page becomes visible. This moment is significant because it indicates when visitors can start engaging with the page content.

For Google, the expected completion time for the LCP phase is a maximum of 2.5 seconds. Anything over 4 seconds is considered “poor performance.”

Clutter in your page or resource codes can negatively affect your LCP time. Initially identifying the LCP area on your page can be beneficial. Writing the style codes for that area inline and deferring other loadings can contribute to improving your LCP time.

Remember, we initially sent a request for the main document upon page opening. During the page load, we also send separate requests for all other resources. Thus, keep in mind that each of these requests has its own TTFB times.

Processing Cost of your Frontend

So far, we’ve primarily focused on connection and loading times. However, displaying all resources on the screen after loading is still the browser’s job. How much we tax the browser is also crucial. For example, parallax images, gradient and animated background colors, or an excessive number of non-standard clicks and scroll tracking can overwhelm the browser and lead to performance issues. Therefore, correctly identifying the primary purpose of our pages during the design phase and keeping these priorities in mind is important. Working with a design team knowledgeable about interface performance can also simplify your task.

Tracking Your Website’s Performance with Observer

In this article, we’ve tried to help you identify the key metrics to monitor your website’s performance, interpret these metrics, and identify problematic areas based on them. I hope this has been useful to you. Of course, not all metrics are limited to those mentioned in this article. However, taking it step by step is crucial, and I hope this framework provides a good starting point.

When you set out to improve your website’s performance, tracking this performance and being aware of changes is critically important. We developed Observer to guide you in this regard. Observer continuously monitors your website, analyzes its performance, offers improvement suggestions based on these analyses, explains these for easy communication with technical teams, and promptly notifies you of any changes, all through a user-friendly web application.

Learn more about Observer
SEO myths

Discover the hidden truths behind SEO that can transform your website’s performance.

Web Hostings

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.

Observer Dashboard

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.

Monitor now for free

Select free plan to meet or have a powerful assistant that includes all our features.