As developers, we have a seemingly endless supply of tools at our disposal thanks to the hard work and generosity of the wider development community who, by and large, share their hard work in the hope of making their peers' lives that little bit easier.

At Go Tripod we're always on the lookout for new ways to streamline our processes and improve the quality of our work. Task runners are a great example of this.

Utilising JavaScript, programs like Gulp and Grunt can automate all kinds of labour-intensive tasks including, for example:

  • compiling, concatenating and compressing assets (eg. images, CSS, JS)
  • live browser reloading for speedy development and testing
  • auto-prefixing for optimal browser support

With these jobs running automatically in the background we're able to focus entirely on the task at hand. This increases productivity and makes sure the code we're writing is as performant and compatible as it can be.

Our current build tool of choice is a modified version of the excellent WPGulp by WordPress aficionado, Ahmad Awais. It does most of the things we need out of the box but since we use Timber to separate logic from styling I've amended it to watch .twig files as well as .php files.

WPGulp compressing assets and watching for changes

Along with a few other minor adjustments, the result is a fast and feature-packed workflow which allows us to build WordPress sites of the highest quality in record time. ????

Back in February I wrote about a font-loading technique I'd implemented on a new project, but there was a problem with it - the script ran on every page load meaning the browser cache was never used to serve the fonts. There are many variations on the same theme with some using session cookies to determine if it's a user's first visit to the site, but they all come with their own quirks to overcome. After further research and testing I decided that, while not fully supported yet, the most effective and future-proof solution to this issue is not a JavaScript solution, but a CSS one.

Enter our old friend, @font-face

The @font-face rule has been around as long as I can remember but went steadily out of favour as the popularity of FOUT techniques grew. This is because its default behaviour results in a FOIT while the font is downloaded and with the rise of mobile devices on sluggish connections users can be left with a blank page for seconds or even minutes. This is no longer the case thanks to a new attribute, font-display.

Browser support for font-display is growing with the latest versions of Firefox, Chrome and Safari all playing ball. It degrades gracefully for all other browsers, falling back to its default behaviour and, as an added perk, we don't need to worry about users with JavaScript disabled.

Optimising fonts

Here at Go Tripod we use Google Fonts for most projects but in their default format (TTF) file sizes can be much larger than is required. On slower connections this means the web fonts will take noticeably longer to swap with the system fonts and it's best we do everything to deliver these assets to the user as quickly as possible. We use Font Squirrel's Webfont Generator to convert our TTFs from Google into WOFF and WOFF2 formats which often reduces their size by over 50% meaning the time it takes to download them is significantly decreased. This coupled with the font-display: swap; attribute means we're providing most users with a superior experience which doesn't rely on JavaScript, falls back gracefully and will soon be supported by all major browsers.

In a previous article I talked about adding the defer attribute to script tags to avoid blocking page render. However, if you’re developing a WordPress theme, chances are you won’t simply be able to amend this HTML. Instead you'll need to make use of the wp_enqueue_script function from within your theme's functions.php file. This function allows you to tell WordPress if your script has any dependancies, which you pass through as an array, and WordPress uses this information to load scripts in the correct order thus avoiding any JavaScript errors. Because plugins load assets via the wp_enqueue_scripts hook it's important you do too so your theme plays nice with them.

So we've got our scripts loading in the correct order - great! But unfortunately WordPress doesn't load them asynchronously for you meaning your HTML will pause parsing while the script is downloaded and executed. Sounds pretty bad for performance, and it is, so we'll be needing an extra something in our functions.php file. While this isn't a perfect solution it's the most solid I've found so far and is what we currently implement here at Go Tripod:

// Defer scripts
// Source: https://www.laplacef.com/2014/05/24/how-to-defer-parsing-javascript-in-wordpress/
if (!(is_admin())) {
    function defer_js($url) {
        if (FALSE === strpos($url, '.js')) return $url;
        if (strpos($url, 'jquery.js')) return $url;
        return "$url' defer onload='";
    }
    add_filter('clean_url', 'defer_js', 11, 1);
}

Your scripts' src attribute will be replaced with itself along with defer and empty onload attributes resulting in them being loaded asynchronously and giving your site a dramatic performance boost.

One of the first things I decided to tackle as part of my recent work on website response times, assuming it’d be a simple process, was render blocking web fonts. Little did I know I was opening up a right can of words (sorry)…

Numerous techniques have been developed over the past few years with varying levels of difficulty, visual effects and results as described in detail here. The two main visual effects that divide opinion are whether to go down the FOIT (Flash Of Invisible Text) or FOUT (Flash Of Unstyled Text) route. There now seems to be a general consensus within the community that FOUT is preferable for UX reasons with most research showing that it’s better to give users something than nothing - this is especially important for users on slow connections and can lead to high bounce rates.

NB: FOFT (Flash of Faux Text) is the new kid in town but I’ve not tried to implement it yet so won’t discuss here.

After some research I decided to go with Web Font Loader, a script born from a collaboration between Google and Typekit to easily load fonts from a variety of services. We want to load this script asynchronously to avoid it blocking page render so the browser will initially display the content using system fonts and apply the web fonts once they’ve downloaded. The example code below is what you’ll need to add within the head to load Open Sans:

<script async defer type="text/javascript">
    WebFontConfig = {
        google: {
            families: ['Open Sans']
        }
    };
    (function(d) {
        var wf = d.createElement('script'), s = d.scripts[0];
        wf.src = 'https://ajax.googleapis.com/ajax/libs/webfont/1.6.26/webfont.js';
        wf.async = true;
        s.parentNode.insertBefore(wf, s);
    })(document);
</script>

One drawback of this approach is its reliance on JavaScript - users with JavaScript disabled will be stuck with system fonts. This is a tiny number of users, around 0.2%, so we can argue this progressive enhancement benefitting 99.8% of users is worth the sacrifice. Of course, if you’re using web fonts that are wildly different to the fallback system fonts loading before them you probably won’t want to use FOUT as the change in style would be too noticeable. In extreme cases this can even lead to changes in layout so, as with all things dev, do make sure you test thoroughly - you wouldn’t want a user on a slow connection to get halfway through a sentence then find it’s moved position!

When working on improving the response time of your site, one of the simplest optimisations to make is the deferring of scripts. In most cases, this can be done with the simple addition of the defer attribute to the script tags within your HTML:

<script src="" defer></script>

When a browser gets to a script tag in your code, its default behaviour is to pause parsing of the HTML, opting to download and execute the script before resuming. Setting the defer attribute tells the browser not to pause, but instead download the script in the background and execute it once parsing of the HTML has completed.

Another feature of using defer, which can be very useful, is that all scripts with the defer attribute will execute in the order they’re presented in your HTML. This is especially useful when writing scripts which rely on others as you can ensure these dependencies are executed first.

Scripts can also be executed asynchronously using the async attribute but bear in mind that it should only be used if the script is not relied upon or does not rely on any others and will function correctly if run before HTML has finished parsing. For a clear visual representation of the different script loading options, this article has some simple infographics I’d recommend taking a look at.

If you’re developing WordPress themes without the use of a template engine like Timber, you may not be able to edit this HTML and should instead make use of the wp_enqueue_script function within your theme’s functions.php file - you should also use this method if using any WordPress plugins which run scripts on your site’s front end.

Grow your business

Find out how we can help

Get in touch