There are a lot of problems that could be plaguing a slow, laggy website. There are a lot of elements that can be optimized to improve your site speed.

Some optimization will result in minor improvements but some optimizations will deliver surprising results. It’s a good idea to first focus on such optimizations that’ll give you good results in less time and effort.

In this article, we’ll discuss two such optimizations that you can perform on your website. These include eliminating render-blocking resources and reducing server response times. These two optimizations can boost your website performance to a whole new level. So, let’s learn a little bit more about these optimizations!


The Opportunities section of your Google PageSpeed Insights report lists all URLs blocking the first paint of your page. The aim is to reduce the effect of these render-blocking URLs by deferring non-critical resources, inlining critical resources, and removing anything unused.

Lighthouse and PageSpeed Insights flags two types of render-blocking URLs: scripts and stylesheets.

A <script> tag that:

l Is in the <head> of the document.

l Doesn’t have a defer attribute.

l Doesn’t have an async attribute.

A <link rel=”stylesheet”> tag that:

l Doesn’t have a disabled attribute. The browser does not download the stylesheet when this attribute is present.

l Doesn’t have a media attribute that matches the user’s device.


To reduce the impact of render-blocking resources, the first step is to identify the critical resources. Under Chrome DevTools, use the Coverage tab to identify non-critical CSS and JS. When you load a page, the tab tells you how much code was used, versus how much was loaded:

To reduce the size of your pages only ship the code and styles that you need. Click on a URL to inspect that file in the Sources panel. Styles in CSS files and code in JavaScript files are marked in two colors:

l Green (critical): This shows styles that are required for first paint; this code is critical to the page’s core functionality.

l Red (non-critical): This shows styles that apply to content not immediately visible; this code is not being used in the page’s core functionality.


After identifying critical code, you must move that code from the render-blocking URL to an inline script tag in your HTML page. Once the page loads, it will have what it needs to control the core functionality of the page.

If there’s code in a render-blocking URL that’s not critical, you can keep it in the URL and then mark the URL with defer or async attributes.

The code that is not being used at all should be removed.


Just like inlining code in a <script> tag, you must inline critical styles required for the first paint inside a <style> block at the head of the HTML page. The rest of the styles should then be loaded asynchronously using the preload link.

You can automate the process of extracting and inlining “Above the Fold” CSS using the Critical tool.

Another way of eliminating render-blocking styles is to split up those styles into different files, organized by a media query. Then you’ll have to add a media attribute to each stylesheet link. When loading a page, the browser only blocks the first paint to retrieve the stylesheets that match the user’s device.

Lastly, you’ll want to minify your CSS to remove all the extra whitespace or characters. This ensures that you’re sending the smallest possible bundle to your users.


The Opportunities section of your Lighthouse or PageSpeed Insights report reports Time to First Byte. It’s the time taken by a user’s browser to receive the first byte of page content:

You r site fails this audit when the browser has to wait more than 600 ms for the server to respond to the main document request. Users don’t like it when pages take a long time to load. Slow server response times are one probable cause for long page load times.

When users navigate to a URL in their browser, the browser makes a network request to fetch that content. Your server receives this request and returns the page content.

The server may need to do a lot of work to return a page with all of the content that users want. So, if users are searching in their order history, the server needs to fetch each user’s history from a database, and then insert that content into the page.

Optimizing the server to work like this as quickly as possible is one way to reduce the time that users spend waiting for pages to load.


To improve server response times, firstly, you need to identify the core conceptual tasks that your server must complete in order to return page content. Then, you must measure how long each of these tasks takes. Once you have identified the longest tasks, search for ways to speed them up.

There can be many possible causes of slow server response times. Therefore, there can be many possible ways to improve:

l Optimize the application logic of the server to prepare pages faster. If you use a server framework, the framework may have some recommendations on how to do this.

l Optimize how your server queries databases or migrate to faster database systems.

l Upgrade your server hardware to have more memory or CPU.


By eliminating render-blocking resources and reducing server response times, you can see a significant improvement in your website page speed. These two optimizations can help improve your website’s performance just enough for it to be presentable and usable. You must do all you can to provide a good page experience to your visitors. Such optimizations go a long way to improving the page speed of your website!




Specializes in website performance optimization and web acceleration. I regularly writes on all subjects and platform related to Speed Optimization