Why page speed matters and how to improve it

It’s no secret: Slow-loading websites frustrate users and cost businesses revenue. Bloated frameworks and poor development choices are typically the most guilty culprits, but even the type of server your site is on or how its configured can play a part.

If you’re building a new website, it’s a lot easier to start off on the right track. But, if you have an existing website that you're dealing with so undertaking the task of speeding up your website seems like an insurmountable challenge. So, where do you start?

What is "page speed"?

First off, let’s quickly talk about what page speed is. Page speed can be described as the time it takes to fully display the content on a specific webpage. You can easily test your website’s page speed using Google's PageSpeed Insights tool.

Google has indicated since 2010 that page speed is one of the signals used by its algorithm to rank pages, and is one of the many factors used to determine whether or not search engines will serve up your webpage in SERPs (Search Engine Results Page). Prior to 2018, Google focused on page speed of desktop loading, but a Google update in July 2018 started to focus on mobile page speed. Google measures "time to first byte" (how long it takes browsers to receive the first byte of information from the web server) when it considers your total page speed.

So essentially, having a slow loading website can negatively impact your rank and overall SEO — which is bad for any small business.

Slow page speed also costs you in other areas outside of SEO, including higher bounce rates, lower average times on pages, and failed sales conversions. Users do not have patience to wait for slow pages to load, and will hop over to your competitor if it means getting a faster experience.

The good news is, issues with your small business website’s page speed can be fixed. Some can get a bit technical, and you may need the help of a web developer in order to implement. Here are a few of the many ways you can increase your page speed.

Optimize assets

Optimizing assets is one of the easiest ways to quickly impact the performance of your website, and simple workflows can be added into any web project. Task runners like gulp allows you to set up pipelines that do just about anything, like minifying CSS and JavaScript as well as optimizing images during a website’s build process. Talk to your developer about their approach to ensure your website’s assets are optimized, and make sure they are at least doing the following:

• Minifying CSS and JavaScript
• Inlining CSS and JavaScript, when possible
• Optimize images and serving them in next-gen formats like .webp with fallbacks
• Removing unused CSS from bloated frameworks and your own legacy stylesheets
• Minifying HTML

Pro tip: Although implementation can be tricky, try integrating a tool like PurgeCSS into your build process to remove unused CSS from bloated frameworks (including your own CSS styles). It can cut down the size of your CSS file by up to 80% or more, so it’s worth the effort.

Enable compression

Your server should be configured to serve text-based assets with compression to minimize the total bytes downloaded to a browser. This is typically a task for your web developer, but the simplest implementation is something like this:

  
    # BEGIN GZIP
    <ifmodule mod_deflate.c>
    AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/x-javascript application/javascript
    </ifmodule>
    # END GZIP
  

This example is for an apache server, and would be placed in your website’s .htaccess file. This snippet sets up gzip compression for text, HTML, XML, CSS, and JavaScript resources. Image compression should be left to your build process, so leave image extensions out of this step.

Pro tip: If your web developer needs a boilerplate .htaccess config to start from, check out HTML5 Boilerplate.

Leverage responsive images

Serve images natively based on the srcset attribute of the img element. Every project's image sizes and requirements are unique, but the basic idea here is to explicitly declare image sizes and viewport widths. This tells the browser to only download the size of the image required based on the screen width of the device the user is on. It also provides the opportunity to manually crop and art direct your images for specific screens. Here's a very basic example of one way you could approach it, and a link to some more info on the technique:

  
    <img srcset="my-image-480w.jpg 480w,
             my-image-800w.jpg 800w"
     sizes="(max-width: 600px) 480px,
            800px"
     src="../my-image-800w.jpg" alt="My image">
  

Defer offscreen images

Now that you’ve optimized your images, you can focus on integrating a load-on-demand approach which defers offscreen images until they are needed.

Loading every image on a page at once is time-intensive, slow, and unecessary. Only load the images that are in view to speed up actual and perceived page load time by integrating a lazy load script into your project.

Examine font usage

Typographical choices directly impact the design of your website, and are capable of conveying trust, professionalism, and status in your visitors. But font files are large and can often load very slowly, especially if your webpage is made up for three or more font families.

Take a look at the fonts — specifically the number of fonts — you or your web designer has chosen to use on your website. If possible, stick to one font that has multiple weights, or cap out your designs at no more than two or three font choices that complement each other.

For example, let’s say you choose Roboto for headings and Open Sans for your body copy. Your Google Fonts embed code could look something like this:

  
    <link href="https://fonts.googleapis.com/css?family=Open+Sans:400,700,800|Roboto:300,400,400i,500,700,900&display=swap" rel="stylesheet">
  

Nine total font families (and all of their characters) are being requested every time the page loads. Are you really using all nine families? Chances are probably not. And if for whatever reason you are, paring down your choices one or two from each family will instantly speed up load time and clean up the design and typographical hierarchy of your website.

Revisit font loading strategies

Now that you’ve streamlined your font choices, adding preconnect to required origins like Google Fonts informs the browser that your page intends to establish a connection to another origin, and that you'd like the process to start as soon as possible. Here’s an example of what that would look like:

  
    <link rel="preconnect" href="https://fonts.gstatic.com/" crossorigin>
    <link href="https://fonts.googleapis.com/css?family=IBM+Plex+Mono:300" rel="stylesheet">
  

If you’re loading fonts server side (your fonts are installed on your web server instead of being pulled from an external source like Google Fonts), there are many techniques you can use to optimize their download times and what happens to your text while the browser is waiting to fetch them. A simple change you can make to a @font-face loading strategy is to leverage the font-display CSS feature in addition to preload to ensure text is visible to the user while webfonts are loading, with the minimal amount of FOUT (flash of unstyled text).

Also, instead of downloading or using every single character in a font, specify that you only want to download latin glyphs by adding unicode-range: U+000-5FF to your import snippet, like so:

  
    <link rel="preload" as="font" href="/assets/fonts/Roboto.woff2" type="font/woff2" crossorigin="anonymous">
    <link rel="preload" as="font" href="/assets/fonts/Roboto.woff" type="font/woff2" crossorigin="anonymous">
    <style>
      @font-face {
        font-family: 'Roboto';
        font-weight: 400;
        font-style: normal;
        font-display: swap;
        unicode-range: U+000-5FF; /* Download only latin glyphs */
        src: local('Roboto'),
             url('/assets/fonts/Roboto.woff2') format('woff2'), 
             url('/assets/fonts/Roboto.woff') format('woff');
      }
    </style>

There are many font loading strategies you can leverage to help improve page speed, so be sure to check with your developer for the one that works best for your website.

Limit or remove render-blocking scripts

The fewer requests a browser has to make to display your website, the faster it will load and the better your page speed ranking will become. You can reduce the impact of these render-blocking URLs (typically links to CSS files and JavaScript files) by inlining critical resources, deferring non-critical resources, and removing anything unused.

Ask your developer to perform a code audit to determine what, if anything, can be removed. After removing unused code, the next step is to combine as many CSS and JavaScript files you can into one of each type to save server requests. This is typically done within a workflow pipeline like the one described above.

It’s never too late to address page speed issues

There are countless factors and approaches you can take to help speed up your website. Although it’s easier to think about page speed at the beginning of a project, using these tips on existing projects can have immediate, significant impact on your page speed and positively influence your organic rankings.

Every project is different, but the ultimate goal should be the same: Design and build your website using smart code that loads fast, provides an excellent user experience, and converts leads.