Untitled RSS Feed

Intro

People use web fonts heavily these days without realising how much impact it would have on the overall page speed.

This doesn’t mean you shouldn’t use them, just the fact that you should know how to use an optimised font and to how to load to reduce the impact on page load.

Optimising web fonts depends on where you host the font, your web application’s design and back end server, your technical abilities and how far your company is willing to invest in this. But don’t let this hold you from following the techniques I will go through, even a little improvement on overall page load counts towards a better user experience.

Finding out how many fonts you are using

Before you start the task, you should find out what fonts are used throughout your website. You can easily find this out using Audit tabs in Chrome DevTools’ network tab and looking at the HTTP requests.

Once in the tab click on the filter icon and look for file extensions like woff, woff2, tff, otf and so on:

Deciding how many is too many

Research shows on average 67% of web pages use custom fonts, with websites averaging between four web font HTTP requests.

Once you figured out how many fonts you are using, you should think about how many fonts you should use. Normally these decisions are driven by UX or design team, but you can definitely have a word with them.

If you are thinking how many is too many, the rule of thumb is that three is crowd and two is the best to stick to.

If you use less fonts throughout your website, not only the number of network requests are reduced, but also the design is more streamlined and consistent.

Choose the subset you need

Unless you have an international website supporting multiple languages, it doesn’t make sense to use all character sets. Choose only what you need and for the languages you use.

Ilya Grigorik a Developer Advocate and Web Perf Guru at Google, explains how you can subset or split web fonts into multiple unicode ranges to deliver only what you need.

You can use the Unicode-range descriptor to specify a list of range values, which can be set out in three different forms:

Single codepoint: indicates a single character.
Interval range: indicates start and of the codepoints of a range of characters.
Wildcard range: ? character indicates any hexadecimal digit.

To demonstrate the possibilities, this is how you can split the Font Awesome into Latin and Japanese subsets. Once done, the browser would download each subset as needed.

Note: Unicode-range subsetting is particularly important for Asian languages, where the number of glyphs is much larger than in Western languages and a typical “full” font is often measured in megabytes instead of tens of kilobytes.

@font-face {
  font-family: 'Awesome Font';
  font-style: normal;
  font-weight: 400;
  src: local('Awesome Font'),
    url('/fonts/awesome-l.woff2') format('woff2'),
    url('/fonts/awesome-l.woff') format('woff'),
    url('/fonts/awesome-l.ttf') format('truetype'),
    url('/fonts/awesome-l.eot') format('embedded-opentype');
  unicode-range: U+000-5FF; /* Latin glyphs */
}

@font-face {
  font-family: 'Awesome Font';
  font-style: normal;
  font-weight: 400;
  src: local('Awesome Font'),
    url('/fonts/awesome-jp.woff2') format('woff2'),
    url('/fonts/awesome-jp.woff') format('woff'),
    url('/fonts/awesome-jp.ttf') format('truetype'),
    url('/fonts/awesome-jp.eot') format('embedded-opentype');
  unicode-range: U+3000-9FFF, U+ff??; /* Japanese glyphs */
}

Note: The local() directive allows you to reference, load, and use locally installed fonts. The url() directive allows you to load external fonts, and are allowed to contain an optional format() hint indicating the format of the font referenced by the provided URL.

There is a catch however which is not all browsers currently support unicode-range. Fortunately most of the major browsers support it, you will need to have a fallback option.

Now if you’re asking how I can determine which subsets I need, the answer is:

If the browser supports unicode-range, then it will automatically select the right subset. You will just need to provide the subset files and specify the appropriate range in the @font-face rules.
If the browser does not support this feature, then you will need to hide all unnecessary subsets, which is, you have to specify the required subsets manually.

You can generate the subsets using an open source tool called pyftsubset tool. In addition to that some font services allow manual subsetting via custom query parameters.

There are some other opportunities you can leverage apart from subsetting. Let’s say you just need a Google font to show your page title. You can specify which characters to download from that font only using a &text= syntax:

<link
  href="//fonts.googleapis.com/css?family=Roboto&text=log"
  rel="stylesheet"
/>

Warning: You need to be careful since this is not a word selector but a character selector. This means characters l, o, and g will be shown on Roboto.

Deliver optimised font formats

There are four major formats used on the web:

Embedded Open Type (EOT): Microsoft designed this format, which is now only used by IE browsers.
True Type Font (TTF): A format that’s been around since the late 1980s that has partial IE support.
Web Open Font Format (WOFF): A format developed in 2009, which is essentially OpenType or TrueType with compression and additional metadata. It enjoys widespread support but is not available in some older browser.
Web Open Font Format (WOFF2): An improvement on WOFF that provides, on average, a 30% reduction in file size. Support is still a work in progress for many browsers.

There isn’t one format that works in all of the browsers, hence the need to deliver multiple formats to provide a consistent experience. From Google developer’s website:

Serve WOFF 2.0 variant to browsers that support it.
Serve WOFF variant to the majority of browsers.
Serve TTF variant to old Android (below 4.4) browsers.
Serve EOT variant to old IE (below IE9) browsers.

If majority of your users use modern web browsers you can get away with specifying just two formats:

@font-face {
  font-family: 'Roboto';
  src: local('Roboto'), local('Roboto'),
    url(fonts/Roboto.woff2) format('woff2'), url(fonts/Roboto.woff)
      format('woff');
}

Always check for the font locally

Some users might already have the fonts installed on their system, so why they should be forced to download the fonts again. You can prevent this by making sure you give precedence to local() in the src attribute of font face rule.

In the above sample note how the src: local is used before the url.

Optimnising the loading and rendering

By default the fonts are lazy loaded, which means the network request is delayed until the render tree is fully constructed, which in turn results in delayed text rendering.

There are three hooks you would need to implement a custom font loading strategy:

<link rel=preload>
CSS font-display property
Font Loading API

Preload your web font

If there is a high chance that the font is used in the page, then you can load the font eagerly using the platform feature: <link rel=preload>.

This will tell the browser that the font should be fetched early, but it won’t specify how to use it. You will need to specify the appropriate CSS @font-face:

<link
  rel="preload"
  href="/fonts/Roboto.woff2"
  as="font"
/>

@font-face {
  font-family: 'Awesome Font';
  font-style: normal;
  font-weight: 400;
  /* will be preloaded */
  src: local('Awesome Font'),
    url('/fonts/awesome-l.woff2') format('woff2'),
    url('/fonts/awesome-l.woff') format('woff'),
    url('/fonts/awesome-l.ttf') format('truetype'),
    url('/fonts/awesome-l.eot') format('embedded-opentype');
  unicode-range: U+000-5FF; /* Latin glyphs */
}

Warning: Not all browsers support this feature, but those who support it also support WOFF2, so you should use that format.

For more info on the other solutions refer to this great post.

Summary

In short these are the points you have to consider when optimising web fonts:

Audit and monitor your font use.
Subset your font resources.
Deliver optimized font formats to each browser.
Give precedence to local() in your src list.
Customize font loading and rendering using <link rel="preload">, font-display, or the Font Loading API.
Specify revalidation and optimal caching policies

Hope this helps you move one more step in the right direction to improve your web application’s performance.

How to fix debugging Flutter in VS Code

Fri, 16 Nov 2018 00:00:00 GMT

Intro

Flutter is a framework created by Google which allows you to build beautiful native apps on iOS and Android from a single codebase.

I recently finished my project at my latest client and had it mind to play with, so I set everything up based on their documentation which to my opinion is the most straight forward doc I’ve ever seen.

You will need to install a few things:

Flutter
Android Studio
An editor of choice (which mine is Visual Studio Code)

Once the setup is done, you will have a hello world app you could make. Flutter uses dart which I find it interesting. It’s similar to Java Script, but it supports types like Type Script (however it is not a super set of JS like Type Script).

You will also need to install one of the android images since you will need it for running your app if you don’t want to test it on an actual device.

When you’re ready just hit debug in VS code and the app runs on the simulator. It’s really fascinating since it uses Material Design theme and it almost looks the same in iOS and Android.

Problem

Now all these was to let you know that currently if you run the app once, exit from it and change something or run it again without change, you will get an error:

Program linking failed. “terminating with uncaught exception of type std::badalloc: std::badalloc” failed

At first I thought I messed something up. So I started stripping my code to see which change has broken the app.

Resolution

Nothing helped, so I started Googling to see if someone else has faced the same issue and there it was.

Based on this thread all I need to do was to add a lunch settings to VS Code and specify the --enable-software-rendering flag:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Flutter",
      "request": "launch",
      "type": "dart",
      "args": ["--enable-software-rendering"]
    }
  ]
}

And that’s it. This will resolve the issue. If you don’t want to use this approach you can also uninstall the app from the simulator and run it again, however, this works sometimes and not always.

They might fix this issue later but for now that’s the way.

Hope this helps you explore more into Flutter and create some awesome apps.

Image optimisation

Mon, 12 Nov 2018 00:00:00 GMT

Recently I had a chance to present a talk at NDC Sydney about web performance and it received a great feedback.

That inspired me to write up a series of posts on each topic I covered in that talk, and who knows, maybe each of these posts would be a talk some day by their own 😃.

All other parts:

Intro

Believe me you don’t want Google to hate your website. Knowing the most heavy weight items on every website are images, it is very important to focus on their optimisation.

Fortunately, reducing their size is very easy and has massive impact on the overall size of the page. For most of the users on a mobile device, the image quality wouldn’t be so important. Even on a desktop with high resolution there are sacrifices you can make. That’s because human eyes won’t detect certain pixels not being present.

As long as you don’t go too far optimising an image to make it ugly, it is a good to continue reducing its size 🤷‍.

Images take more than %50 of a web page’s overall weight 😱. That’s why we should optimise them!


Average bytes per page 2018

What does image optimisation mean

Image optimisation is referred to reducing image sizes using different techniques. This will result in the page being loaded faster, hence having a better user experience.

Why bother

Here are some benefits you would gain by optimising your images:

It will improve the page load time. For every second users have to wait for the page to load, Amazon will lose $1.6 billion in sales per year (you may now pick a calculator and see how much your company would be impacted 😁).
It improves your SEO capabilities, your site will rank higher in search engines resulting in more traffic.
Creating site backups will be faster (if you are using a CMS or if you backup the whole site)
Smaller image sizes use less bandwidth, resulting in not draining user’s mobile data quota.
Requires less storage space on the server (or CDN), makes it more cost effective.

Let’s optimise them

The primary goal of image optimisation is to find the balance between file size and image quality. But before we start on optimisation tips, we should understand different image formats and when to use each.

Choose the right format

PNG – produces higher quality images, but also has a larger file size. Was created as a lossless image format, although it can also be lossy.
JPEG – uses lossy and lossless optimization. You can adjust the quality level for a good balance of quality and file size.
GIF – only uses 256 colors. It’s the best choice for animated images. It only uses lossless compression.

There are some newer image formats like WebP and Jpeg2000, but the browser support is not there yet. In summary you should use JPEG for images with lots of colour and PNG for simpler images.

Size vs Compression

This is an example of an image before and after compression. Note how the quality is impacted (you can’t see it in the cat, but around it):

Before

After

For the same reason that you can’t figure out the difference in the cat itself between the first and second image, it is safe to compress image to that degree. Just to let you know the first image is 4mb and the second is only 27kb. 🤷‍

Lossy vs Lossless Optimisation

Now that you know how important it is to compress images and reduce the quality, it is also important to know we have two types of compression:

Lossy - this is kind of a filter to eliminate some data from the image, in the above example you could see some loss in the area around the cat. Using this technique, the file size will be reduced to a large degree. Tools such as Adobe Photoshop, Affinity Photo or some free online tools such as Image Compressor will do the trick for you.
Lossless - this is a filter that does not eliminate any data, but uses compression only to reduce the size, but it means it requires images to be uncompressed to operate. You can do this easily using tools like FileOptimizer and ImageOptim.

You will need to experience it yourself and find the sweet spot for your images. It is a task which requires some work beforehand but saves you a lot of time later. Another thing to consider is to use these tools like ImageOptim in your build process, this way you don’t even need to worry about doing it upfront. And your original images remain untouched.

Using the right dimension

As important as compression is, by itself it can go only so far keeping the same dimension. After you apply the compression you cannot reduce the size with the same width and height anymore.

Apart from this, you will need to know that showing a picture with 2000px width on a mobile device is not such a good idea. Especially on smaller devices the human ability to detect changes are far less than when they are looking at a bit monitor with a large aspect ratio.

To achieve this you can use the srcset and width descriptors attribute in HTML. With this, you can mention multiple screen sizes and specify which image to use for each size.

When you use width descriptors, you’re providing the browser with a list of images and their true width so that it can select the best source based on the viewport size.

Using SVGs

SVG is a scalable vector format which works great for logos, icons, text, and simple images. Here are a couple reasons why you would consider using them:

SVGs are automatically scalable in both browsers and photo editing tools. This is a dream for a web and graphic designers!
Google indexes SVGs, the same way it does PNGs and JPGs, so you don’t have to worry about SEO.
SVGs are traditionally (not always) smaller in file size than PNGs or JPGs. This can result in faster load times.

Here is an example to show you how much difference it can have (Images from https://genkihagata.com):

JPEG

Size: 81.4KB

PNG

Size: 85.1KB

SVG

Size: 6.1KB

Lazy loading images

When we consider all we’ve gone through so far, you would realise at some point that it is not enough to make images smaller anymore. Especially if you have too many of them in the page. This is where we need to make sure our web page loads with them fast instead.

This is where lazy loading comes to rescue. Let’s see a demonstration on how it works (video from CSS Tricks):

What is it?

Lazy loading images is simply the act of not loading images until a later point in time. It is a technique in web development which applies to many other form of resources, but here we are focusing on images.

Wikipedia: Lazy loading is a design pattern commonly used in computer programming to defer initialization of an object until the point at which it is needed. It can contribute to efficiency in the program’s operation if properly and appropriately used.

How it is done

Imagine you have a very long page with a lot of images. Why would the image at the bottom of the page get loaded if the user cannot see it. As simple as that, you can load the image on an event like when that part of the page is visible (using scroll event handler) or any other event. But not just when the page loads.

Apart from that, if the user never scrolls down, that image wouldn’t get loaded, resulting in saving some network traffic and data usage for the end user.

You will start to see a lot of benefits considering how much impact this has on the overall page load time and speed.

Lazy loading techniques

There are two common ways of loading an image on a page, using an img tag, and CSS background-image. Let’s start with the image tag.

Image tag

Here is a simple image tag we normally use to load an image:

<img src="/path/to/some/cat/image.jpg" />

The markup for lazy loading images is pretty similar. The src attribute is the trigger for the browser to send a network request and fetch the image. No matter if this is the first or the 50th image on your page.

To defer the load, simply use data-src attribute.

<img data-src="/path/to/some/cat/image.jpg" />

Since the src is empty the browser doesn’t load the image when the tag is rendered. Now it is just the matter of triggering the load which normally is done when the image is entered the viewport.

We can use events like scroll, resize, and orientationChange to figure out when to trigger the load. The scroll event is pretty clear, when the user scrolls if the image tag is on the page then we trigger the load and tell the browser to fetch the image. However, the resize and orientation change events are equally important. The resize is when the user changes the window size like when they make the window smaller. The orientation change happens when the user rotates their device.

Once we hook into these events, we can enable lazy loading and the result is really good:

document.addEventListener(
  'DOMContentLoaded',
  function() {
    var lazyloadImages = document.querySelectorAll(
      'img.lazy'
    )
    var lazyloadThrottleTimeout

    function lazyload() {
      if (lazyloadThrottleTimeout) {
        clearTimeout(lazyloadThrottleTimeout)
      }

      lazyloadThrottleTimeout = setTimeout(
        function() {
          var scrollTop = window.pageYOffset
          lazyloadImages.forEach(function(img) {
            if (
              img.offsetTop <
              window.innerHeight + scrollTop
            ) {
              img.src = img.dataset.src
              img.classList.remove('lazy')
            }
          })
          if (lazyloadImages.length == 0) {
            document.removeEventListener(
              'scroll',
              lazyload
            )
            window.removeEventListener(
              'resize',
              lazyload
            )
            window.removeEventListener(
              'orientationChange',
              lazyload
            )
          }
        },
        20
      )
    }

    document.addEventListener('scroll', lazyload)
    window.addEventListener('resize', lazyload)
    window.addEventListener(
      'orientationChange',
      lazyload
    )
  }
)

Using intersection API

Let’s see what this API offers:

The Intersection Observer API provides a way to asynchronously observe changes in the intersection of a target element with an ancestor element or with a top-level document’s viewport.

Opposite to the previous technique where you might see some performance impact on the page because of all of those event handlers, this approach is relatively new.

This API removes the previous performance hit by doing the math and delivering a very efficient way to call a callback function when the resource is on screen:

document.addEventListener(
  'DOMContentLoaded',
  function() {
    var lazyloadImages

    if ('IntersectionObserver' in window) {
      lazyloadImages = document.querySelectorAll(
        '.lazy'
      )
      var imageObserver = new IntersectionObserver(
        function(entries, observer) {
          entries.forEach(function(entry) {
            if (entry.isIntersecting) {
              var image = entry.target
              image.src = image.dataset.src
              image.classList.remove('lazy')
              imageObserver.unobserve(image)
            }
          })
        }
      )

      lazyloadImages.forEach(function(image) {
        imageObserver.observe(image)
      })
    } else {
      var lazyloadThrottleTimeout
      lazyloadImages = document.querySelectorAll(
        '.lazy'
      )

      function lazyload() {
        if (lazyloadThrottleTimeout) {
          clearTimeout(lazyloadThrottleTimeout)
        }

        lazyloadThrottleTimeout = setTimeout(
          function() {
            var scrollTop = window.pageYOffset
            lazyloadImages.forEach(function(img) {
              if (
                img.offsetTop <
                window.innerHeight + scrollTop
              ) {
                img.src = img.dataset.src
                img.classList.remove('lazy')
              }
            })
            if (lazyloadImages.length == 0) {
              document.removeEventListener(
                'scroll',
                lazyload
              )
              window.removeEventListener(
                'resize',
                lazyload
              )
              window.removeEventListener(
                'orientationChange',
                lazyload
              )
            }
          },
          20
        )
      }

      document.addEventListener(
        'scroll',
        lazyload
      )
      window.addEventListener('resize', lazyload)
      window.addEventListener(
        'orientationChange',
        lazyload
      )
    }
  }
)

We attach the observer on all the images we want to be lazy loaded. When the API detects that the element has entered the viewport, using the isIntersecting property, we pick the URL from the data-src attribute and move it to the src attribute for the browser to trigger the image load like before. Once this is done, we remove the lazy class from the image and also remove the observer from that image.

CSS background image

CSS background images are not as straightforward as the image tag. To load them the browser needs to build both the DOM tree and CSSDOM tree (see here). If the CSS rule is applicable to the node the browser loads it, otherwise doesn’t. So all we need to do is to not give it a background property by default and add it when it’s visible:

document.addEventListener(
  'DOMContentLoaded',
  function() {
    var lazyloadImages

    if ('IntersectionObserver' in window) {
      lazyloadImages = document.querySelectorAll(
        '.lazy'
      )
      var imageObserver = new IntersectionObserver(
        function(entries, observer) {
          entries.forEach(function(entry) {
            if (entry.isIntersecting) {
              var image = entry.target
              image.classList.remove('lazy')
              imageObserver.unobserve(image)
            }
          })
        }
      )

      lazyloadImages.forEach(function(image) {
        imageObserver.observe(image)
      })
    } else {
      var lazyloadThrottleTimeout
      lazyloadImages = document.querySelectorAll(
        '.lazy'
      )

      function lazyload() {
        if (lazyloadThrottleTimeout) {
          clearTimeout(lazyloadThrottleTimeout)
        }

        lazyloadThrottleTimeout = setTimeout(
          function() {
            var scrollTop = window.pageYOffset
            lazyloadImages.forEach(function(img) {
              if (
                img.offsetTop <
                window.innerHeight + scrollTop
              ) {
                img.src = img.dataset.src
                img.classList.remove('lazy')
              }
            })
            if (lazyloadImages.length == 0) {
              document.removeEventListener(
                'scroll',
                lazyload
              )
              window.removeEventListener(
                'resize',
                lazyload
              )
              window.removeEventListener(
                'orientationChange',
                lazyload
              )
            }
          },
          20
        )
      }

      document.addEventListener(
        'scroll',
        lazyload
      )
      window.addEventListener('resize', lazyload)
      window.addEventListener(
        'orientationChange',
        lazyload
      )
    }
  }
)

And:

#bg-image.lazy {
  background-image: none;
  background-color: #f1f1fa;
}
#bg-image {
  background-image: url('path/to/some/cat/image.jpg');
  max-width: 600px;
  height: 400px;
}

Summary

We’ve seen how to reduce the image size using different compression methods, how to load different sizes for different screen sizes and at last how to lazy load them. Using these techniques, you can improve the performance of the page so much it becomes a hobby for you after some time to play with.

And as always please spread the word and behold for the next post on web fonts 😃👋.

Optimising JavaScript

Fri, 12 Oct 2018 00:00:00 GMT

Recently I had a chance to present a talk at NDC Sydney about web performance and it received a great feedback.

That inspired me to write up a series of posts on each topic I covered in that talk, and who knows, maybe each of these posts would be a talk some day by their own 😃.

All other parts:

Time to see what we can do for our old friend JavaScript. So let’s begin.

Switch to HTTP/2

With more and more hosting providers supporting HTTP/2, it’s becoming a good time to switch to this protocol instead and benefit from its multiplexed nature. What it means in terms of performance is that we don’t need to bundle all of our JavaScript into large bundles to reduce the number of calls to server.

With HTTP/2 designed to handle large number of requests, you can now increase the number of files required to render the page. Not too much tho:

Too much of a good thing is a bad thing.

Async & Defer

As I mentioned before, JavaScript, like CSS is a render blocking element. This simply means the browser needs to wait for it to load and execute before it can parse the rest of the HTML document.

This hugely increases our First Meaningful Pain. In order to fix this issue we can use two of the features which are not used by many people but are very effective.

Normal execution

When you use a <script> to load a JavaScript file, it interrupts the parsing of the document. Browser fetches the resource, executes this and then continues on paring:

The `Async` attribute

The Async attribute is used to indicate that this resource can be executed asynchronously. The parsing doesn’t need to be halted, it can be done right after the resource is fetched from network and is ready.

<script async src="script.js">

This attribute can be used only on external JavaScript files. The file would be downloaded in parallel and once the download is finished, the parsing is paused for the script to be executed:

The `Defer` attribute

The Defer attribute is used to tell the browser to execute this script after parsing the whole document.

<script defer src="script.js">

Like Async this file gets downloaded in parallel but the execution only happens when the whole HTML document is parsed:

At the end remember to put all of your script tags right at the end of the body to prevent more delay in parsing your HTML.

As for the browser support, fortunately these attributes are fully supported by all of the major ones.

Code splitting

Most of the modern sites will bundle all of their JavaScript into one, resulting in an increase in load time and suffering from load performance.

Code splitting allows you to split your application code into separate chunks and lazy load them when needed. This also means minimum required code to client and improve the page load time.

You can split your code in three areas:

Vendor code
Entry point
Dynamic splitting

Vendor code

Vendor code like Angular, React, moment, etc. can be separated from your main code. Webpack has full support for this and other methods. This technique allows you to have better control over cache invalidation of your bundles whenever your app or vendor code changes independently of one another.

This is something every app should do.

Entry point

This technique separates your code by entry points in your app. These points are where bundlers like webpack start from, when they build a dependency tree of your app.

This is bar far the easiest way to split code, but it is manual and has some pitfalls:

If there are any duplicated modules between entry points, they will be bundled in both.
It isn’t as flexible and cannot be used to dynamically split code with your app logic.

This technique is not suitable for when you have client side routing or when you have a mix of server side rendering and a single page app.

Dynamic splitting

Separate code when dynamic import are used. This is the best option for single page applications. Having different modules for different routes in your SPA is an example of this.

Do I even need code splitting?

This is one of many times when you hear me say it depends (I am a consultant after all 😉). If your app has many routes with isolated functionality and heavily uses frameworks and libraries, this answer is most probably YES.

However, it is up to you to decide whether you need it or not by your own understanding of your app structure and code.

Import wisely

If you use npm or other package management systems for your dependencies, then you will have a lot of extra and unneeded files in your buid folder.

When using a framework or a library, make sure you investigate wether they have separate modules you can import and if yes, only import what you need.

For instance, let’s assume you are using underscore, but only use groupBy, shuffle, and partition. Most people import the whole library like this:

import * as _ from 'underscore'

Instead of this, you could just import what you need:

import {
  groupBy,
  shuffle,
  partition,
} from 'underscore'

This way you only bring what your need and the bundlers will take care of the rest for you. Your total package size and as a result your page load time will decrease.

Throttling and debounce

Ok, enough about the size, let’s see where else we can improve our performance.

Many times you have to add an event listener to do something, like listening to page scroll. Then we forget that the listener fires every time the event is triggered.

window.addEventListener('scroll', function() {
  console.log('page scrolled')
})

In the above example, the message is printed into console whenever you scroll. Imagine you have some heavy operation in that callback function, this would turn into a big performance bottleneck.

If you can’t remove that event listener and use a different approach, then you can use either debounce or throttle to alleviate the situation.

Debounce

This feature enforces a function call to not happen until some time has passed since it’s last call. For example, call the function if 100 millisecond has passed from it’s last call.

Look at this implementation from underscore:

const debounce = (func, delay) => {
  let inDebounce
  return function() {
    const context = this
    const args = arguments
    clearTimeout(inDebounce)
    inDebounce = setTimeout(
      () => func.apply(context, args),
      delay
    )
  }
}

Now we can debounce our event listener for every 100 millisecond:

var efficientScrollListener = debounce(
  function() {
    console.log('page scrolled')
  },
  100
)

window.addEventListener(
  'scroll',
  efficientScrollListener
)

Throttle

Throttling is similar to debounce but different since it will enforce the maximum number of times a function can be called over a period of time. For example execute this function once every 100 millisecond.

Here is a simple implementation:

const throttle = (func, limit) => {
  let inThrottle
  return function() {
    const args = arguments
    const context = this
    if (!inThrottle) {
      func.apply(context, args)
      inThrottle = true
      setTimeout(
        () => (inThrottle = false),
        limit
      )
    }
  }
}

Now we can throttle our scroll event listener:

var efficientScrollListener = throttle(
  function() {
    console.log('page scrolled')
  },
  100
)

window.addEventListener(
  'scroll',
  efficientScrollListener
)

So what

I hope I have given you enough information on just some of the areas you can focus to improve your applications performance when using JavaScript. If you would like to have other topics covered please comment below and I will add them here or in another post.

And as always don’t forget to share the ❤️.

How to use Preload/Prefetch to boost load time

Sat, 06 Oct 2018 00:00:00 GMT

Recently I had a chance to present a talk at NDC Sydney about web performance and it received a great feedback.

That inspired me to write up a series of posts on each topic I covered in that talk, and who knows, maybe each of these posts would be a talk some day by their own 😃.

Link to all other parts:

OK, just to recap, here are the rules from part 1:

Stream HTML to client
Send minimal CSS and send it fast

In this part, we’re going to see how we can request our resources before we need them. You might be wondering why we want to do so, and the answer is, if you want to send minimal CSS to client, or any other resource for that matter, you need to break them into smaller pieces and load them separately.

There are some techniques which allow you to do it like lazy loading, but with lazy loading, user has to wait (most probably watching a spinner 😏) until the resource is loaded.

But, we can do better. One of the letters from PRPL pattern stands for pre-cache. An effective way to load your resources before they are required, cache them and then use them when they are needed. We can achieve this using preload and prefetch features of browsers.

Before we go further into how, let me explain their difference:

Preload

<link rel="preload"> tells the browser that the resource should be loaded as part of the current navigation and it should start fetching it ASAP. This attribute can be applied to CSS, fonts, images, JavaScript files and more. When using this attribute you will also tell the browser what file type this file has, which can be set in an as attribute:

<link
  rel="preload"
  as="script"
  href="super-important.js"
/>
<link
  rel="preload"
  as="style"
  href="critical.css"
/>

So by now you should have guessed that preload is used in the current route and resources fetched via this technique are very important. The difference between using rel=preload and rel=stylesheet is that browser will know about that resource way ahead of time allowing the download to start sooner.

If you are trying this for your stylesheet and don’t see your styles get applied, it is because there is a catch when using preload which is the browser downloads the resource but won’t apply it until we tell it to. To get it working you will need a bit of JavaScript:

<link
  rel="preload"
  as="style"
  href="critical.css"
  onload="this.rel='stylesheet'"
/>

What happens now is that the styles get applied as soon as the file is loaded.

Prefetch

<link rel="prefetch"> is different from <link rel="preload"> in that it is not trying to load a critical resource faster, it is trying to load a non-critical resource sooner.

Resources loaded by this technique are loaded after current page is loaded, page load event is finished and bandwidth is available. This means it is ideal for lazy loading future routes’ resources or resources that user might need later. Some use cases are fetching a next page if pagination is used:

<link rel="prefetch" href="page-2.html" />

By the time user clicks on next page button, the page is already loaded and the app feels real fast.

To read more about the usage of these features and also know about other useful features, have a look at Google developer’s resource prioritisation page.

Same catch applied for prefetch as well. But since we are loading a resource which is required potentially for a different route, you might have a separate rel=stylesheet on that page which uses this in memory file or in case of a SPA just set the rel to stylesheet when the route is loaded.

When to use these

So to emphasise why we need to know about these techniques, let me take you back to part one. CSS is a render blocking element, so we need to break it down to the smallest possible chunk which is required to render our main route. Then we can use the above techniques to either load the resource later in the same page without blocking the rendering or to load the resource which is required for our possible next route beforehand and use it when needed.

Hope this has helped you to get started with optimising your HTML and CSS loading so far.

Next post will be on JavaScript and what we can do there to improve our web application’s performance.

Alla prossima 😎.

Improve HTML and CSS performance

Sat, 29 Sep 2018 00:00:00 GMT

Recently I had a chance to present a talk at NDC Sydney about web performance and it received a great feedback.

That inspired me to write up a series of posts on each topic I covered in that talk, and who knows, maybe each of these posts would be a talk some day by their own 😃.

Link to all other parts: