How to make websites as fast as possible

Overview

Slow websites and applications are deal breakers for most visitors.

Speed and ‘Health’ go hand in hand with websites. A fast website is beneficial to businesses in many ways:

• Better experience for your users
• More security and reliability
• More user interactions
• More SEO

Search engine bots factor load times for the pages they index. If certain performance metrics hit a threshold, the pages will be flagged for having a poor experience by Google and many others.

Many things must happen on a technical level, when requesting and receiving content from a server. With that, there are many 3rd party tools with their own algorithms and metrics. The most widely used is Google’s Lighthouse.

Ultimately it’s about letting your visitors access your site without having to wait!

Google Lighthouse

Lighthouse is a tool that Google uses to analyze the speed of a webpage. Anyone can use it for free.

According to Google, the two metrics for the Core Vitals of a webpage are, “Cumulative Layout Shift” or CLS, and “Largest Contentful Paint” or LCP. More on what these and other metrics mean below.

Google records both “Lab Data” and “Field Data” - where lab data is their tests, and field data is the real-world load times of your visitors. Based on the person’s internet connection, the device they’re on, and so on; lab data varies from field data. When running tests on Chrome or Pagespeed insights, we can simulate thresholds for processing and bandwidth. Most people in the United States have high-speed internet and 4g or 5g internet. So there are different resource considerations for national and international traffic.

Metrics for Speed

There are many metrics for measuring the speed of a web page. Here are some important ones:

Time to First Byte (TTFB) - Lighthouse doesn’t use this as its 6 most important metrics, it is technical rather than user-perceived. TTFB is the moment the user’s device receives its first byte since its request from your server. Your server and backend code both play a part in the FCP and TTFB.

First Contentful Paint (FCP) - Sort of like TTFB and Server Response Time, FCP is the first instance of a user seeing anything other than a white screen from the time of the initial request from your server.

Time to Interactive (TTI) - How long it takes until the user is able to interact with the page. You’ll notice websites that run a lot of code or large images take time after they’re seemingly loaded, to be able to scroll down or interact in any way. The computing power of the user’s device also plays a role. Therefore mobile devices are more impacted, by resources that require heavier computing, like Javascript and Images.

Total Blocking Time (TBT) - The amount of time spent loading render-blocking resources. More on render-blocking resources in the section below.

Largest Contentful Paint (LCP) (Core Web Vital) - What Google considers 1 of 2 most important metrics. How much time it takes for the largest Content Element of the screen to be rendered. Usually the main headline text of a page. It’s an important metric because many other things rely on it, like server responsiveness, file sizes; it’s when the first important content of the page, above the fold, is visible to the user.

Cumulative Layout Shift (CLS) (Core Web Vital) - The other most important metric of all - CLS is a mathematical calculation of how many pixels every element on the page moved during the render process. Because this is visible to the user, what we call elements “jumping on the screen”. It’s annoying when a page jumps through page loads, it’s unwanted flashing. The CLS metric is also vital because it doesn’t let people trick Google into thinking their website has good UX just because it’s fast. Search engine companies are constantly improving their algorithms for many reasons. CLS is a metric focused on perceived speed and user experience.

Google’s Recommendations

The recommendations for speeding up a site can seem overwhelming, but following good web practices makes it less of a burden.

Reduce Server Response Time - This is often one that most people can’t get past, and it’s often the first they come across. It relates to your server, and how long it took to respond to the request of the user. Many variables exist along the way, such as the quality of the server, and what it must do to produce the webpage.

Avoid redirects - Redirects add to load times, as a browser takes time to correct itself based on the response it gets from a website. You should be aware of this when running tests and setting up links within your site as well. That means, if the final destination of a page or resource ends in example.com/ then you want to test and link to that URL exactly. Linking to example.com without the trailing slash would technically be a redirect too.

Reducing CSS - Cascading Style Sheets is the design language for web pages. While modern sites rely on compilers and tools for automatically generating minimal code, manual work is still needed in almost all cases. CSS code, when rendered before the contents of a page are considered “render-blocking”. Meaning, the rest of the page is waiting for the CSS to be processed by the user first. Style loads before content, otherwise, people would get content without style, then a flash on the screen when the style loads.

Reducing JS - As with reducing CSS, Google will make this recommendation with basically any amount of JS code you have. At some point, you’ll have to determine when you’ve reduced enough, before having to cut back on features. JavaScript is heavier on mobile than for desktop since it requires more work to parse and process. JavaScript is used on most sites, for animations, behavior tracking, and interactivity.

Reducing External Requests - Most websites refer to other sites for assets, like Adobe for fonts. It is not uncommon for a modern site to request dozens of resources from external sites. While modern devices can handle simultaneous connections at once, the less the faster. Companies go to great lengths to optimize bandwidth and how connections are made on very large sites.

Deferring non-critical resources

This simply means, only load things when they’re needed. Non-critical resources meaning any resource that is not totally necessary or the site is not dependent on.

Eliminating Render-Blocking resources

Render-blocking resources are typically Fonts, CSS, and JS files. These files halt the rest of the page from loading while they’re being downloaded by the client. By eliminating the resource you would be either deleting it, or moving it from the header to the footer.

Prefetching Resources

It is possible to start loading the most important resources as soon as a connection is established between the server and the client.

Generating Critical CSS

You can generate critical CSS manually, with a tool, or have it integrated into the workflow. This means, getting all of a webpage’s most important style rules loaded first, and the remaining style can be loaded in the footer externally. Critical CSS is best kept minimal and served inline.

Image Optimization

The goal with web images is to produce the highest quality images that are small in size. More details coming later.

Less Code, Smaller Files, More Speed

Visiting a webpage is nothing but your browser requesting files from a webserver. The smaller those files, the faster the visitor can get them.

Every character on a document adds 1 byte to the file. Whether a space, letter, or number, 1 byte at a time!

Minification - By removing the extra white space and line breaks in your code, minifying reduces file sizes by 10-30%.

Compilers - CSS Compilers like Sass and PurgeCSS post-process code to minify it in more ways than simply reducing spaces.

Compression - Compression is available on most web servers, and we’ve gotten good at it. Text and code files get compressed down to about 10-30% their original size.

Inline vs External File - Code can be served directly from a webpage itself, or from a separate file. Certain code is better placed inline, while most code is stored in external files.

Optimizing Fonts

Fonts can be an unexpectedly heavy resource, with different ways to optimize their delivery. Fonts are render-blocking like with CSS and JS. That is, the contents of a page won’t load until the fonts are loaded. Unless, you can tell the browser to render a fallback font first, then the text will flash and change to the loaded font, which you see often. When ‘font-swapping’ is enabled however, it can result in FOIT (Flashing of Invisible Text).

Native fonts are a great option, the font of no font. That is, letting the user’s device decide to use the font that came with it. It’s technically the most performant choice, and arguably a wise design choice too.

Other Optimizations

Prefetching Urls

You can establish a connection with an external domain before the resource is requested, this saves time and is known as URL Prefetching. For example, if a chat widget or external file needs to be served later in the load, the connection can be established to that server before requesting the files at the right time on the page.

Preloading Links

It’s something like speed perception magic. When a user hovers over a link, you can start requesting resources from that page before they’ve clicked on it; or based on other conditions.

Prioritizing critical resources

Performance optimization often bleeds into the design too. It’s important to assess what resources are most critical to be served first. And this can depend on the page within your site. The most optimal site would be one that delivers only what the user needs first, on every page. While carefully deciding what those resources should be.

Reducing render-blocking code

CSS and JS files that the content of a page depends on are render-blocking.

Combining Files

While this was a popular thing to do for a while, with the introduction of HTTP/2 it’s no longer necessary on most servers. File combination was crucial before HTTP/2 since back then, a user could request a couple of files from a server at a time. With HTTP/2 a server can handle dozens of simultaneous connections to a user making file combination do more harm than good in many cases.

Server Configuration

Server configurations can also bottleneck performance, and most hosting plans do not come “tuned up” out of the gate. Depending on your stack, you may have control over the performance of your webserver.

Database Maintenance

Websites connected to a database can get slowed down over time as unused data piles up. Cleaning up and optimizing a database can speed up a site too.

Rendering

After a device’s web browser has processed code, it needs to present it on the display. This is the process of rendering, with regards to websites. Rendering is part of the whole process of serving a webpage. For example, animations can be programmed in many different ways, some animations require less graphics processing than others. Same with oversized, high definition images.

While a device is trying to parse and process a lot of code, it can also use up its resources at that moment to make its graphics perform slower.

Rendering is yet another process that can be avoided when building minimally from the start.

Above the fold

Above-the-fold refers to the very first or top section of a web page that is visible to the user. Anything below the fold is not as important or critical to load right away. The term critical is often used in development, performance optimization, and design.

User-Perceived Speed

Aside from the technical details of your speed, as it’s evaluated by bots. Your users are constantly evaluating it too. There is what’s known as perceived speed. Where you can, for example, improve your scores with Google and Bing, but have a perceivably unpleasant order of how a page is now rendered.

Resource Budget

Every website has a limited resource budget. Based on your server’s performance, and what’s necessary to conduct business, a webpage can’t and shouldn’t have it all. For example, wanting to have a slideshow above the fold on every page, with high resolution images, maps, and so on, on a site filled with code, will use a lot of bandwidth and processing to run, compared to something more plain. This can add up to thousands per year in costs on a high traffic website. Making it notable to always consider the resource budget of a website. Websites with low visitors can get away with oversized pages, but it doesn’t excuse having a sluggish experience for visitors.

More speed measurement tools

There are more ways to evaluate the speed of a site. I may use some of these tools to provide reports on your speed.

• Google’s Lighthouse
• Pingdom Test Tool
• GT Metrix
• TestMySite
• Chrome Developer Tools
• Firefox Developer Tools