Reducing Server Response Time

User Experience

User Experience is a term used to describe the quality of how a potential customer interacts with your company. It begins with the first interaction with your business—your company website. This is where your website’s performance becomes important. Analyzing key website metrics related to user experience will help you to make improvements that actually matter.

A slow web server response triggers a couple of responses with the audience:

• That your site is down, which is an almost instantaneous hard bounce for almost 100% of your audience.
• The second is attention span. When the load time is slow, they move on.

We know this from our own experience and our own expectations. If anything, the web has made people more demanding and less patient.

Time to First Byte

Time to First Byte (TTFB), also known as server response time, is the total amount of time it takes for the browser to receive the first byte in response to the browser request. 

Reducing TTFB is critical to your visitors’ page experience as it affects every resource referenced in your HTML, and directly influences how long it takes for your page to load.

A slow TTFB may negatively affect your front-end resources as your visitors may only see a blank page while the browser is waiting for a response from the server.

Reducing TTFB can significantly improve performance. There are tools available to test the performance of your website. Drilling down into the test results will help you target rirtems tat are slowing down your TTFB.

Waterfall Chart

“Waterfall” charts produced by testing sites like GTmetrix help to illustrate the resource load required to load a webpage. Careful analysis of the waterfall chart can reveal what items are causing bottlenecks in the load time.

Potential Server Issues

• RAM
  Web servers run on software, but more important, they run on available memory (RAM). If your web server has too much traffic that exceeds existing capacities, the server will start running out of RAM. Every web page you serve occupies RAM. When there are too many of these pages and instances in RAM, a bottleneck develops as new pages and web server instances must wait until space is freed up by closed connections.
• CPU
  If your web page depends on data, middleware, access to separate servers or anything else that might require additional calculations on the server side, a CPU bottleneck can develop in much the same way the RAM issue develops. This particular problem is a little easier to diagnose because CPUs are much easier to precisely monitor than RAM usage.
• SERVICES
  Problems can occur using microservices or facilities connected from other domains. Fonts, for example, when served from a central repository, can bring a web site down if the font server is overloaded or unavailable. The same goes for shared Javascript libraries, database capacity, cloud servers, calculation engines or anything else that is “outsourced” from your server to some other domain’s machine.

Server Checklist for Troubleshooting

GTmetrix provides an excellent list of items that it audits to look for response time issues:

• Avoid an excessive DOM size
• Avoid chaining critical requests
• Avoid CSS @import
• Avoid document.write()
• Avoid enormous network payloads
• Avoid large layout shifts
• Avoid long main-thread tasks
• Avoid multiple page redirects
• Avoid non-composited animations
• Avoid serving legacy JavaScript to modern browsers
• Combine images using CSS sprites
• Defer offscreen images
• Efficiently encode images
• Eliminate render-blocking resources 
• Enable Keep-Alive
• Enable text compression
• Ensure text remains visible during webfont load
• Keep request counts low and transfer sizes small
• Minify CSS
• Minify JavaScript
• Minimize main-thread work
• Preconnect to required origins
• Preload key requests
• Properly size images
• Reduce initial server response time
• Reduce JavaScript execution time
• Reduce the impact of third-party code
• Remove duplicate modules in JavaScript bundles
• Remove unused CSS
• Remove unused JavaScript
• Replace large JavaScript libraries with smaller alternatives
• Serve images in next-gen formats
• Serve static assets with an efficient cache policy
• Use a Content Delivery Network (CDN)
• Use explicit width and height on image elements
• Use HTTP/2 for all resources
• Use passive listeners to improve scrolling performance
• Use video formats for animated content
• User Timing marks and measures