Adrian Bece

Follow this tutorial and learn how to apply a new font loader for Gatsby that works with both web fonts and self-hosted fonts. 

We developed a font loader plugin for Gatsby - Prototyped 

In the past few weeks I was familiarizing myself with Gatsby and I was making a list of plugins that are good-to-have while working on a project. I went through the SEO plugins, SVG plugins, data source plugins, and finally, I wanted to check out some font loader plugins when I noticed something strange.

Here are the top two Gatsby plugins for fonts.

And if we open any of those two, we are greeted by the following message and README .

Most-used plugins are abandoned, deprecated and not actively maintained.

Don't get me wrong, it's totally okay for authors and companies to back down from developing and maintaining an open-source repo. I think it would be better to transfer the ownership to someone who wants to continue the development beforehand rather than leaving it as is and archiving it.


Asynchronous font loading

That missing support for the most-used plugins was my primary motivation to develop the font loader plugin, but what do font loaders even do?

In short, font loaders help eliminate render-blocking resources, in this case, fonts and their respective CSS files. I've gone into more detail about render-blocking resources in one of my previous articles.

How to eliminate render-blocking CSS and JavaScript - PrototypedHow to improve website performance and achieve great results? This tutorial brings you answers on how to eliminate render-blocking CSS and JavaScript to improve website performance.Prototyped - Thoughts from the folks at PROTOTYPAdrian Bece

When a website document is loaded, it automatically starts downloading high-priority resources that are needed before displaying the page - CSS, JavaScript, images, iframe, videos, fonts... Depending on how we instruct the browser, we can load some of those resources after the page has been displayed (rendered). By doing this, we are displaying the content as fast as possible to the user and loading all non-critical resources afterward to speed up the loading process.

This is especially true for web fonts, like Google fonts for example. During our page load, we are requesting a font CSS file from Google servers which also requests additional font files from Google CDN. Our page is not displayed until this chain of request resolves which can take some time depending on the CDN performance and user's internet connection.

With asynchronous loading, we can give a low priority to the font file and CSS and load it after the page is displayed. Although this has improved site performance, we have created a minor visual issue - Flash of Unstyled Text (FOUT).


Flash Of Unstyled Text (FOUT)

If the font is loaded after page content is displayed, we can see the moment the font changes between the fallback (default) font and the main web font that has been loaded asynchronously. This event is called Flash Of Unstyled Text or FOUT, for short. This change might even affect the page layout, size of some elements and even cause some visual bugs because the page is styled with web font in mind.

What we can do to make this effect much less noticeable is:

 * Choose the fallback font that looks as closely as possible to the web font that is being loaded asynchronously
 * Adjust font size, line height, letter spacing and word spacing to match the web font as closely as possible

After adjusting the fallback font CSS, we get the following result.

You might be asking: how can we detect when the font has been download and applied to the document?

We'll have to use JavaScript to detect that event. In case of Gatsby, I've written a plugin that both loads the web font asynchronously and it listens to font load event and applies a CSS class to HTML body element to handle FOUT.


Gatsby omni font loader plugin

During the past week, I've been working on creating a Gatsby plugin that will use the recommended way of loading fonts and enable devs to handle FOUT easily.

And few days ago, I've published Gatsby Omni Font Loader that can work with both web fonts and self-hosted fonts, add preload and preconnect on SSR, add font asynchronously, and handle FOUT. All in one small, neat package.

You can check out the source code on Github. Feel free to submit issues, feature requests and pull requests. Support and contribution are very much appreciated!

codeAdrian/gatsby-omni-font-loaderFont loader optimized for maximum performance. Removes render-blocking font resources and loads them asynchronusly. Handle FOUT &amp; FOUC with font loading status watcher. Supports both local-host...GitHubcodeAdrian


Installation

Start by installing the plugin with NPM or Yarn.

npm install --save-dev gatsby-omni-font-loader



or

yarn add --dev gatsby-omni-font-loader




Configure the plugin

In gatsby-config.js file, reference the gatsby-omni-font-loader plugin in the plugins array and configure it.

Below is the sample config and explanation for each of the options available.

{
  /* Include plugin */
  resolve: "gatsby-omni-font-loader",

  /* Plugin options */
  options: {

    /* Enable font loading listener to handle FOUC */
    enableListener: true,

    /* Preconnect URL-s. This example is for Google Fonts */
    preconnect: ["https://fonts.gstatic.com"],

    /* Self-hosted fonts config. Add font files and font CSS files to "static" folder */
    custom: [
      {
        /* Exact name of the font as defied in @font-face CSS rule */
        name: ["Font Awesome 5 Brands", "Font Awesome 5 Free"],
        /* Path to the font CSS file inside the "static" folder with @font-face definition */
        file: "/fonts/fontAwesome/css/all.min.css",
      },
    ],

    /* Web fonts. File link should point to font CSS file. */
    web: [{
        /* Exact name of the font as defied in @font-face CSS rule */
        name: "Staatliches",
        /* URL to the font CSS file with @font-face definition */
        file: "https://fonts.googleapis.com/css2?family=Staatliches",
      },
    ],
  },
}




Handling FOUT

When enableListener: true is set in plugin config in gatsby-config.js, HTML classes are being added to <body> element as the fonts are being loaded.

HTML class name format will be in the following format

wf-[font-family-name]--loaded

You can use the Font Style Matcher to adjust the perfect fallback font and fallback CSS config and use the styles from there.

Here is the example of how body element will look like after all fonts are being loaded (depending on the config).

<body class="wf-font-awesome-5-brands--loaded wf-font-awesome-5-free--loaded wf-staatliches--loaded">



So the CSS will look something like this

body {
 font-family: "Merriweather", Georgia, sans-serif;
 /* default styles */
}

body:not(.wf-merriweather--loaded) {
 /* fallback font (Georgia) CSS config */
 /* line-height, letter spacing, font-size... */
}

body:not(.wf-merriweather--loaded) h1 {
 /* fallback font (Georgia) CSS config */ 
 /* line-height, letter spacing, font-size... */
}

.wf-merriweather--loaded {
 /* web font CSS config */ 
 /* line-height, letter spacing, font-size... */
}

.wf-merriweather--loaded h1 {
 /* web font CSS config */ 
 /* line-height, letter spacing, font-size... */
}

Thank you for taking the time to read this post. Feel free to share your thoughts about this topic in the comments or drop us an email at hello@prototyp.digital. 😄

Development

We developed a font loader plugin for Gatsby

Find answers in this tutorial and learn how to eliminate render-blocking CSS and JavaScript to improve website performance. 

How to eliminate render-blocking CSS and JavaScript - Prototyped 

In my previous post, I've talked about how I boosted Lighthouse scores for my personal website by implementing native lazy loading with fallback.

Best way to lazy load images for maximum performanceLazy loading is important for optimizing image loading and therefore improving web performance. This article covers how to implement native lazy loading with fallback for unsupported browsers.Prototyped - Thoughts from the folks at PROTOTYPAdrian Bece

Another important improvement that boosted my performance and Lighthouse score was eliminating render-blocking resources.


Critical and non-critical resources

When we usually build a project, we like to include everything we need right out of the box - all styles, JavaScript plugins, JavaScript code, fonts, images, etc. We usually do this to make sure that no async loading errors happen while we develop the project.

The reality is that browser needs to load, parse and run everything we include when website loads, which can make the first paint (with no cached resources) unnecessarily slow. It's called render-blocking because browser is wasting time and resources parsing the code that is unnecessary for the initial page load and not displaying the page content.

When we take a look at our resources (CSS, JavaScript, fonts, etc.) we can sort them into two categories:

 * Critical resources - code that's critical to the page's core functionality.
 * Non-critical resources - code not being used in page's core functionality and a code that runs after the page is loaded or on user interaction.

So let's take a look how we to handle critical and non-critical CSS and JavaScript resources.


Handling critical CSS

Critical CSS refers to the styles that are necessary for styling above the fold content. Above the fold content that is visible to users when they first load the page (top section of the page).

In order to add critical CSS to the page, we need to remove those styles from the CSS stylesheet and add them directly to HTML in a <style> tag inside a <head> element.

<head>
  

  <style>
    /* Add critical styles here */
  </style>

  
</head>

This approach may increase HTML document size a bit, but those changes are insignificant if you use compression algorithm like GZIP or Brotli for HTML delivery.

Adding critical CSS directly to HTML document ensures that those styles and parsed and applied on the first paint (initial load).


Handling non-critical CSS

In order to make the critical CSS effective, we need to tell the browser how to handle non-critical CSS and display the page. It also allows us to use the website while the additional non-critical CSS loads. Depending on Internet connection speed, you might not even notice the additional styles being loaded.

In order to handle non-critical CSS, we need to change how the CSS file which contains those styles loads.

<head>
  

    <link crossorigin rel="preload" href="/path/to/styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
    <noscript><link rel="stylesheet" href="/path/to/styles.css"></noscript>

  
</head>

This may look like a hack at first, but this is a really smart and efficient way of loading CSS in an efficient way with proper fallback:

 * link rel="preload" as="style" loads the CSS file in a non-render-blocking way.
 * onload="this.onload=null;this.rel='stylesheet'" makes sure that CSS file is parsed and loaded after the site loads and the onload function is deleted.
 * noscript fallback makes sure that the CSS loads the standard way if JavaScript is not available.

It's also important to note that we can load Google Fonts stylesheets in the same efficient way!

<link crossorigin rel="preload" href="https://fonts.googleapis.com/css2?family=Montserrat:wght@400;600&display=swap" as="style" onload="this.onload=null;this.rel='stylesheet'">

<noscript><link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Montserrat:wght@400;600&display=swap"></noscript>




Firefox issue & handling IE

At the time of writing this article, Firefox has a bug related to preloading CSS. This efficient way of loading non-critical CSS currently isn't working on Firefox, but it should be fixed soon.

You might want to provide a fallback for browsers that do not support preloading or have issue with it (like Firefox). Luckily, this is really easy to do with inline JavaScript.

<script>
    var isIE = !!window.MSInputMethodContext && !!document.documentMode;
    var isFirefox = navigator.userAgent.toLowerCase().indexOf("firefox") > -1;

    if (isIE || isFirefox) {
        var pageStylesheet = document.createElement("link");
        pageStylesheet.rel = "stylesheet";
        pageStylesheet.type = "text/css";
        pageStylesheet.href = "/path/to/styles.css";
        document.head.appendChild(pageStylesheet);
    }
</script>



We just need to add this code before body closing tag to insert the regular link element into head element for Firefox and IE browsers which do not support preloading.


Handling critical JavaScript

We handle critical JavaScript the similar way we handle critical CSS, by inlining it within HTML code. It's important to note that we need to insert critical JavaScript code using script tag before the body closing tag. That way we make sure that JavaScript doesn't block content render and all available DOM nodes are created and available to JavaScript code.

<body>
  

  <script>
    /* Inlined JavaScript code */
  </script>
</body>




Handling non-critical JavaScript

We can handle non-critical JavaScript just by adding defer or async tags to script tag (inline JavaScript or JavaScript loaded from src).

 * We use defer for scripts that need the whole DOM and/or their relative execution order is important. It tells the browser to load the page first and then load the script in the background.
 * We use async for independent scripts that can be executed in any order. This script doesn't wait for any other scripts and can loaded in parallel with other scripts with async scripts.

<script defer src="/path/to/script.js"></script>
<script async src="/path/to/script.js"></script>




Boosted performance & Lighthouse score

On my personal website I've handled critical and non-critical CSS and JavaScript as I've described in the article. After implementing this modern approach, I've eliminated render-blocking, non-critical CSS and JavaScript which in turn boosted my Lighthouse score and overall performance!

Thank you for taking the time to read this post. Feel free to share your thoughts about this topic in the comments or drop us an email at hello@prototyp.digital. 😄

Improving website performance by eliminating render-blocking CSS and JavaScript

How to implement native lazy loading with fallback for unsupported browsers? Take a look at this tutorial and find out how to set it. 

Best way to lazy load images for maximum performance - Prototyped

Image lazy loading is one of the more popular approaches of optimizing websites due to the relatively easy implementation and large performance gain. With lazy loading we load images asynchronously, meaning that we load images only when they appear in the browser's viewport.

Almost a year ago, native lazy loading for images and iframes was released for Chrome and other major browsers. The point of the feature is to give browsers control when to request an image or iframe resource, which makes dev jobs a bit easier. Up to that point, only option was to use various JavaScript plugins which monitored the viewport changes and loaded resources dynamically. Now browsers can do that natively!

At the time of writing this article, around 73% of currently used browsers support this feature which is not bad, but we don't want to make the website image content inaccessible and unusable to 27% of potential users.

So this puts us in an interesting situation:

 * We want to use the benefits of native lazy loading for browsers that support it
 * We want to use a JS plugin as fallback for lazy loading for browsers that don't support it
 * We don't want to load the lazy loading JS plugin if the browser supports native lazy loading.
 * Support both img and source elements is mandatory


The "loading" attribute

We have three possible values that we can use for loading attribute.

 * auto - default value. Same as not setting the attribute.
 * eager - load the resource immediately.
 * lazy - load the resource once it's in the viewport.

Although it depends on the use-case, generally we want to use eager value for resources above the fold and lazy value for resources below the fold.


Modern approach

We need to write a script that will run after the HTML document is loaded. I've used Jekyll and added the script as an include that was appended to the end of the HTML body element. This is the most effective way of running JavaScript functions to avoid render blocking.


Image markup

We want our JavaScript function to start the image loading process based on the native lazy loading feature support. To achieve that we'll add the path to our images to data-src instead of src. But we shouldn't leave src empty, so we'll use 1x1px transparent image placeholder. Our markup for img elements will look something like this:

 <img 
    src="/path/to/placeholder/image.png"
    data-src="/path/to/full/image.jpg"
    alt="Image description"
    class="lazyload"
    loading="lazy"
/>

Please note that class="lazyload" is used by the lazyload fallback plugin. I've used lazysizes that uses this particular class name.

Additionally, we want to support picture element that contains multiple source element and fallback img element.


<picture>
    <source data-srcset="path/to/image.webp" type="image/webp" />
    <source data-srcset="path/to/image.jpg" />
    <img loading="lazy" 
        class="lazyload"
        src="path/to/placeholder/image.png"
        data-src="path/to/image.jpg"
        alt="Image description"
    />
</picture>


Feature detection

We need to detect if user's browser supports native lazy loading. Luckily, we can do that using JavaScript directly.

if ("loading" in HTMLImageElement.prototype) {
      /* Native lazy loading is supported */
   } else {
      /*  Native lazy loading is not supported */
   }


Final JavaScript code

For native lazy loading, we only need to assign data-src value to src value for img and source elements and let the browser handle the rest.

For unsupported browsers, we only need to load the JavaScript plugin and, optionally, run it (if not done automatically). I've used lazysizes but any plugin will work, just make sure that the markup is correct (class names, data elements, etc.).

So the final JavaScript code will look something like this:

<script>
    if ("loading" in HTMLImageElement.prototype) {
        var images = document.querySelectorAll('img[loading="lazy"]');
        var sources = document.querySelectorAll("source[data-srcset]");
        sources.forEach(function (source) {
            source.srcset = source.dataset.srcset;
        });
        images.forEach(function (img) {
            img.src = img.dataset.src;
        });
    } else {
        var script = document.createElement("script");
        script.src = "/link/to/lazyload.js";
        document.body.appendChild(script);
    }
</script>


Boosted performance & Lighthouse score

On my personal website I've used a JavaScript plugin for image lazy loading for all browsers. After implementing this modern approach, I've eliminated one JavaScript file that is being loaded and parsed on website load which in turn boosted my Lighthouse score and overall performance!


More image optimization techniques for maximum performance

Lazy loading is one of many ways to optimize image performance on the web. I've wrote this in-depth posts that covers other important techniques and aspects of image optimization for the web like web-specific image formats, using CDN, progressive images, etc.

Optimizing images for the web - an in-depth guide - PrototypedFollow this in-depth-guide and learn different ways to optimize images for your website.Prototyped - Thoughts from the folks at PROTOTYPAdrian Bece



Thank you for taking the time to read this post. Feel free to share your thoughts about this topic in the comments or drop us an email at hello@prototyp.digital. 😄

Best way to lazy load images for maximum performance

This is how I improved my UX skills while developing eCommerce websites. Understanding these UX concepts helped me become a better web developer. 

10 UX lessons I learned on eCommerce projects - Prototyped

I have worked as a certified Magento 1 and Magento 2 frontend developer for an eCommerce agency for 4 years. I’ve developed and maintained several webshops ranging from small scale to enterprise shops and I’ve audited numerous websites for frontend performance and UX.

After moving onto non-eCommerce projects, I’ve noticed that I could apply the lessons I’ve learned while working on eCommerce to create very user-friendly and performant frontends with great UX features.

In this article, I will present a general overview of some of the lessons and UX best practices that I’ve learned throughout my 4-year career working on eCommerce projects.


Reduce user’s effort where possible

An eCommerce website can make the shopping experience as clear and simple as possible by providing various helpful features:

 * Saved billing & shipping addresses
 * Saved payment methods
 * Easy login (social media login)
 * Fast checkout with saved customer details
 * Customer wishlist
 * Clear shopping flow (uniform CTA elements)
 * etc.

By reducing the effort that the user has to invest in shopping and focusing the effort only on areas that require it, we can increase the conversion and overall revenue.

With that in mind, we can work on reducing the user effort by offering the user various ways of speeding up and simplifying the flow. It’s important to take note of repeating processes in the flow and processes that could be automated or sped up.


Header & first impression of a website

Header and its navigation represent the webshop brand, informs the customer about types of products and services that it offers and provides helpful information.

It has several functions:

 * Represents the brand (with logo)
 * Navigation gives a general overview of the product catalog (top-level categories)
 * Displays account state (guest or logged in)
 * Displays cart state (amount of products in the cart)
 * Displays a search element (input or a toggle)
 * (optional) Provide only the most helpful links (FAQ, billing, shipping, returns, etc.)

Looking at the header, the customer needs to become familiar with the branding and instantly know what kind of content and general topics that can be found on the website. Alongside that, the header needs to provide helpful tools and links that can make the site navigation easier.


Call To Action elements

In eCommerce, Call To Action (CTA elements) need to have the most visual weight on the page, be uniform and lead the user down the path from browsing the product catalog, adding individual product(s) to the cart, and successfully finishing the checkout.

For example, the “Subscribe” button on a Newsletter element should have less visual weight than the “Add to cart” button.

CTA elements that have the most visual weight on the site need to guide a user in the main website flow or the flow they choose to follow. Having many CTA elements on the page can be confusing to the user, so it’s important to establish an element hierarchy and use the appropriate element for a context (primary flow, secondary flow, optional flow, etc.).


Importance of responsive design

There are more users accessing the web from a mobile device than a desktop device, so more and more customers are using mobile devices to shop online. More and more websites focus on having a great, if not superior, UX on mobile and tablet devices. Revenue and number of purchases on mobile and tablet devices continue to grow year after year.

“79% of smartphone users have made a purchase online using their mobile device in the last 6 months

Almost 40% of all eCommerce purchases during the 2018 holiday season were made on a smartphone.”

- Source: Mobile eCommerce Stats in 2018 and the Future Online Shopping Trends of mCommerce

By using analytics tools like Google Analytics, we can determine the ratio of users using mobile devices to users using desktop devices and track various metrics (like conversion rates) for each group. Website owners and management can make various decisions when improving the site or planning new features.


Every second of loading time matters

How much does each second of loading cost?

“Pages that loaded in 2.4 seconds had a 1.9% conversion rate.

At 3.3 seconds, conversion rate was 1.5%.

At 4.2 seconds, conversion rate was less than 1%.

At 5.7+ seconds, conversion rate was 0.6%.”

- Source: Cloudflare — How Website Performance Affects Conversion Rates

It’s not all that surprising that users will abandon the site if it loads too slow. In the context of an eCommerce site, if a user abandons the site due to the large loading times right before checking out, it results in a revenue loss.

Many webshops found that improving the loading times and optimizing the frontend and backend resulted in a significant revenue increase.

“Walmart found that for every 1 second improvement in page load time, conversions increased by 2%. COOK increased conversions by 7% by reducing page load time by 0.85 seconds. Mobify found that each 100ms improvement in their homepage’s load time resulted in a 1.11% increase in conversion.”
Source: Cloudflare — How Website Performance Affects Conversion Rates

After working on eCommerce projects, I’ve started optimizing code and asset file size right from the start, eliminating any potential performance bottlenecks right from the start. These bottlenecks and issues are common for all websites.


Using schema.org to describe the content

By adding schema.org tags to a website, Google and other search engines can better understand the site they crawl and display. schema.org is just a collection of simple HTML attributes that can be easily added to websites. There are a lot of use-cases and tags that can describe your website in great detail and can be a topic of a future article due to the number of possible use-cases and options.


Here are some useful links on how to implement schema.org tags

 * Schema.org schemas
 * How to use schema.org for eCommerce websites
 * Understand how structured data works


Analyzing user flow to determine performance bottlenecks — category page example

The standard category page consists of a product catalog (displayed in a grid or a list), a toolbar with sorting and display options, layered navigation (filters) and pagination.

This layout usually also applies to the search results page.

From what we know, we can notice the following:

 * This page is reloaded each time user interacts with filters, sorting options, display options, pagination or the search page
 * Images play the biggest part in page size and number of requests

For example, If there are 24 products displayed on a category page with only 8 items in the user’s viewport on load, we are downloading 16 images that the user might not even see, but it slows down a page load considerably (depending on image size and optimization).

With that in mind, the best improvement that we can do on a category page is to optimize image sizes and add lazy loading.

By following user flow, we can determine potential bottlenecks on the page and optimize them from the start. It’s also helpful to be aware of the type of content that is going to be on the page (images, text, videos) and apply optimization techniques accordingly.


User focus and forms — checkout page example


Removing distracting page elements

When the user decides to check out and buy the items in their cart, we need to ensure that the user doesn’t get distracted and leaves the checkout page. The best way of doing that is to simplify the header and footer (or remove footer entirely). Ideal checkout page consists of the following elements:

 * Header with branding only — the user is reassured that they are on the same website, but they are not distracted by navigation and links
 * Checkout form — divided into sections or steps.
 * Security section (short info, lock icon, etc.) — the user is reassured that the data they provide in checkout (address, payment data, etc.) is safe and that they can trust the website.

Let’s take a look at the example of a simplified page layout on checkout.

First, let’s take a look at how the header looks like on the homepage.

And this is how it looks like on checkout. It keeps the user focused on the checkout form, while reassuring users that they’ve stayed on the same website.

We have the ability to guide the user’s focus while the user browses the website. It’s important to know when we need to reduce the number of distracting elements on the page to focus the user on the important flow or give the user many focus points on the page.


Form layout

Often times, it’s tempting to create multi-column forms, but this can cause some issues. Users can take different paths when filling out those forms.

This can become very confusing to the user and they could lose the sense of progression, and might not check out successfully.

By keeping the form inputs in a single column and dividing them into sections and steps customers can scan the inputs more clearly, have a better sense of progression and have a better chance of successfully submitting the form and following the user flow.


Form validation

On checkout, form validation needs to happen as the user is typing data.

If we run validation when the user clicks the “Submit” button and there is an error somewhere in among a handful of inputs, the user needs to go back and find the error and fix it before proceeding. This ruins the user’s sense of progression and doesn’t reassure them that their data is valid in time.

Additionally, required fields need to be clearly marked and their labels need to stand out more prominently in the form.

If the data like address or telephone needs to follow a certain pattern or format, this needs to be clearly communicated to the user via tooltip next to the form.

Additionally, you can also use those tooltips to reassure users that their email and/or telephone number will only be used for purposes important to the website flow and not for promotion (unless the user doesn’t explicitly gives permission).


Looking for more UX best practices?

Micah Bower's awesome article Paving the Path to Purchase – eCommerce UX Best Practices covers more best practices for making your eCommerce website even more usable and customer-friendly.


Conclusion

After 4 years of working in the eCommerce industry, I’ve learned how properly follow the user flow on the page and pinpoint potential performance and UX bottlenecks, various UX best practices, how every second of load time matters, etc. I’ve successfully managed to apply these lessons when I moved onto projects beyond eCommerce and it changed the way I’ve looked at and analyzed the websites.

I hope that you’ve found this article helpful and that you’ll be able to apply these UX improvements in your projects. I’ve only covered a handful of UX lessons I’ve learned, but feel free to share your own UX tips and thoughts in the comments.

Design

UX lessons learned from eCommerce projects

Follow this in-depth-guide and learn ways to improve CSS performance and file size.

Improving CSS performance and file size - in-depth guide - Prototyped

Table Of Contents

 * What makes CSS slow
 * File size
 * CSS rendering
 * Reducing CSS file size
 * Minification
 * Optimization
 * Compression
 * CSS structure
 * Improving CSS animation performance
 * Transitions and animations
 * Promoting element into a composite layer
 * will-change property
 * contain property
 * Bonus: CSS Performance tips


What makes CSS slow?


File size

Large file size results in larger download times and parsing times. It's simple as that.


CSS Rendering

In order to understand where CSS rendering bottlenecks may come up, we need to look at the render pipeline steps:

1. Style - Determines which CSS rules apply to which elements in an HTML document.

2. Layout - Determines where the element is positioned on the screen and how much space does it take. CSS properties: position, top, left, right, bottom, etc.

3. Paint - Determines visual elements. CSS properties: color, border, background-color, etc.

4. Composite - Draws layers onto the screen. CSS properties: opacity and transform.

CSS offers a lot of options in terms of animation and transitions. We can create a transition on a lot of CSS properties. There are transitions and animations which can use GPU and perform really well, resulting in smooth 60 FPS (Frames per second) experience with fluid and smooth animations. On the flipš side, there are CSS properties that, when animated, can result in low FPS and choppy animations.

Any changes or updates happening on one of the steps cause updates on the following steps. We can see that the Layout step is the most expensive to animate and Composite step is the least expensive to animate.


Reducing CSS file size

By decreasing the file size of the CSS file, we can decrease the download time and loading time. Some improvements related to file size can be done even when we are finished working with CSS making it a very effective optimization. For maximum efficiency, it's best to keep in mind and apply these improvements from the start.


Minification

CSS file minification is an easy win and should be the first step for achieving better CSS performance. Minification removes formatting characters inside the CSS file (whitespaces, line breaks, etc.) which are only useful to us (makes the code readable).

/* Non-minified code */

.card {
  padding: 1rem;
  background-color: #aaa;
}

/* Minified code */

.card{padding:1rem;background-color:#aaa}


There are numerous online, automated and CDN "uglifying" tools that will help you with minification. Tools for CSS minification:

 * CSS Compressor - simple online minification
 * CSSNano - Automated CSS optimizer + minifier
 * Clean CSS - Automated CSS optimizer + minifier


Optimization

Wait... We've already minified our CSS file. Isn't it already optimized?

Well, technically it is. When talking about CSS optimization, we are looking at removing unnecessary CSS or reformatting CSS properties that reduce the number of characters. Unlike minification, this improvement cannot be done on CDN and it must be done when code is being compiled (by a tool like Webpack or Gulp).

Let's take a look at the following example.

/* Unoptimized CSS */

.card {
  background-color: #aaaaaa;
  padding: 0.5rem 1rem 0.5rem 1rem;
}

.card__content {
    padding: 0.5rem 1rem 0.5rem 1rem;
}


At first look, this looks like any regular CSS that anyone would write and not think twice about it. But there are some optimizations that could be done to reduce the number of characters.

/* Optimized CSS */

.card {
  background-color:#aaa;
}

.card,
.card__content {
  padding:.5rem 1rem;
}


We have reduced the number of characters from 132 to 85 (a 35% reduction). Let's apply minification and see the final result.

/* Optimized CSS with minification */

.card{background-color:#aaa}.card,.card__content{padding:.5rem 1rem}


We have reduced the number of characters from 132 to 68 (48% reduction in total).

You can see how much CSS impact the optimization has. The reduction is a result of removing the DRY code which can be avoided in this simple example. Looking at the CSS file with thousand of lines of code which is being changed on a regular basis (especially if split into several files), we can easily make our code less DRY. Luckily, there are tools that help us optimize our code and keep it DRY.

In the previous section, we have mentioned two of the numerous tools for optimizing CSS with minification included:

 * CSSNano - Automated CSS optimizer + minifier
 * Clean CSS - Automated CSS optimizer + minifier


Compression

Compression is done server-side. It uses gzip or Brotli to compress and further reduce the file size in order to reduce the file download time.

This topic is very extensive and covers more file types than just CSS. CSS tricks wrote a great article on this topic if you are interested in implementing server-side compression.

It's also important to note that most CDN services offer the compression option out of the box.


CSS structure

Having a good CSS structure and using various CSS best practices and also result in a lower-sized CSS file when minified. For example, using BEM and only class selectors with low specificity will result in fewer characters in the file and the lower file size.

I've covered CSS structure improvements in one of my previous posts. By following these CSS principles, you will have a CSS file with great structure, DRY code and a great foundation for optimization and minification.

Improve your CSS with these 5 principlesWriting CSS is really simple and straightforward, so why is there a need forprinciples and best-practices while writing CSS? As the project scope increases and as the number of people working on theproject increases, the problems become more and more apparent and can causeserious issues down the…Prototyped - Thoughts from the folks at PROTOTYPAdrian Bece


Improving CSS animation performance


Transitions and animations

We've covered the CSS rendering pipeline and what makes animation slow. So basically, Layout step is the most expensive to animate and Composite step is the least expensive to animate.

If we look at the CSS properties that cause the Composite layer to update, they are transform and opacity. These two properties use hardware (GPU) acceleration, resulting in very performant updates.

If you apply a transition to position attributes like top or left, animation performance will be poor because we are updating the Layout step which forces both Paint and Composite to update. Replacing the position CSS properties with transform and using transition on it, we are updating Composite step only, resulting in smooth animation.


Promoting element into a composite layer

We aren't really restricted to using only transform and opacity for smooth animations. CSS offers quite a few ways of "promoting" an element into a composite layer to tell the browser that this element will have its Paint CSS properties updated often.

The hacky and "old way" of doing this is by either adding backface-visibility: hidden; or transform: translate3d(0,0,0);. In most cases, these properties won't affect your element in any way (if they don't override anything), but they will make the browser move the element into Composite layer, significantly improving animation performance.

.example {
  width: 20rem;
  height: 20rem;
  background-color: #aaa;

  border-radius: 0;
  backface-visibility: hidden;
  transition: border-radius 0.3s ease-in-out;
}

.example:hover {
  border-radius: 50%;
}




will-change property

A modern way of telling browsers which element is expected to be updated (in terms of CSS rendering) is setting the will-change property.

.card {
  background-color: #aaa;
  transition: background-color 0.3s ease-in-out;
  will-change: background-color;
}

.card:hover {
  will-change: background-color;
}

.card:active {
  background-color: #bbb;
}


There are several things to keep in mind when using will-change:

 * Don't apply will-change to too many elements.
 * Use sparingly
 * Don't apply will-change to elements to perform premature optimization.
 * Give it sufficient time to work.


contain property

The contain CSS property represents the future of CSS render pipeline optimization. Currently, it sits at limited browser support. It allows us to indicate that an element’s subtree is independent of the rest of the page. This allows the browser to recalculate layout, style, paint, size, or any combination of them for a limited area of the DOM and not the entire page.

contain: none; /* No optimization */
contain: strict; /* Equivalent to contain: layout paint size style */
contain: content; /* Equivalent to contain: layout paint style */
contain: size; /* component size is set and no descendant will modify its size.  */
contain: layout; /*  changes to any descendant of this element will not affect the layout of any outside element and vice versa.  */
contain: style; /* descendant’s styles will not affect outside elements.  */
contain: paint; /* you specify that no descendant will display outside the elements bounds. Similar to overflow: hidden; */


Example of using contain CSS property:

.box {
  contain: layout size; /* Won't change size nor affect layout */
}



<div class="box">
  <div class="box__content">...</div>
</div>




Bonus: CSS Performance tips


Avoid using @import

@import CSS property is used to include a CSS file within another CSS file. The issue is that these files are then loaded one after another instead of parallel when using the recommended HTML way of including stylesheets.


Use HTTP/2 if you have multiple stylesheets

HTTP/2 brings noticeable performance improvements when loading a lot of smaller files. This is an ideal solution if you are using CSS structure that results in multiple CSS stylesheets (individual screens, modules, components, etc.).

If you are not using HTTP/2, it's recommended to merge all your CSS files into a single CSS file.


Be aware of "expensive" properties

Some properties are more resource-heavy and increase render time. If you are intending to support devices with lower processing power, being aware of these properties would be beneficial:

border-radius
box-shadow
filter
position: fixed

*
:nth-child



Serve CSS file(s) over the CDN

Serving static files like images, CSS, JS, etc. from CDN improves download times. Additionally, some CDN services offer basic minification and optimization options, so you can easily get a performance boost if your code is not minified already.


Keep your selectors simple

Having simple class selectors (consider using BEM and OOCSS or other flavors and combinations) can benefit performance when rendering your site, especially on devices with lower processing power. I've covered this topic more in-depth in one of my previous articles:

Improve your CSS with these 5 principlesWriting CSS is really simple and straightforward, so why is there a need forprinciples and best-practices while writing CSS? As the project scope increases and as the number of people working on theproject increases, the problems become more and more apparent and can causeserious issues down the…Prototyped - Thoughts from the folks at PROTOTYPAdrian Bece

Thank you for taking the time to read this post. Feel free to share your thoughts about this topic in the comments or drop us an email at hello@prototyp.digital.

Improving CSS performance and file size - an in-depth guide

Discover which 5 principles will make the CSS code more maintainable, extensible, understandable and cleaner.

Improve your CSS with these 5 principles - Prototyped

Writing CSS is really simple and straightforward, so why is there a need for principles and best-practices while writing CSS?

As the project scope increases and as the number of people working on the project increases, the problems become more and more apparent and can cause serious issues down the line. Fixing issues may become harder, duplicated code, complex override chains and use of !important, leftover / unused code (removed elements or features), code that is hard to read, etc.

Writing CSS at a professional level will make the CSS code more maintainable, extensible, understandable and cleaner. We're going to look at the five simple and very effective principles that will take your CSS to the next level.


Naming principle

"There are only two hard things in Computer Science: cache invalidation and naming things." -- Phil Karlton

Properly naming and structuring your CSS selectors is the first step to making your CSS more readable, structured and cleaner. Establishing rules and constraints in your naming convention makes your code standardized, robust and easier to understand.

This is why concepts like BEM (Block-Element-Modifier), SMACSS (Scalable and Modular Architecture for CSS) and OOCSS (Object Oriented CSS) are popular among many frontend developers.


Low specificity principle

Overriding CSS properties is very useful, but things can go out of hand pretty quickly on more complex projects. Overriding chains can get really long and complex, you might be forced to use !important to solve the specificity issue and you could get really easily lost when debugging or adding new features.


/* Low-specificity selector */
.card {}

/* High-specificity selectors */
.card .title {}

.blog-list .card img {}

.blog-list .card.featured .title {}

#js-blog-list .blog-list .card img {}

Browser and specificity

One of the benefits of following the low specificity principle is performance. Browsers parse the CSS from right to left.

Let's take a look at the following example:

.blog-list .card img {}

Browsers parse the selector like this:

 1. Find all img elements on the page
 2. Keep selected elements that are the descendants of .card class
 3. Keep selected elements that are the descendant of .blog-list class

You can see how high-specificity selectors impact performance, especially when we need to globally select generic elements like div, img, li, etc.


Using the same level of specificity

By using low specificity CSS class selectors in combination with BEM or one of the other naming principles mentioned in the previous section, we can create a performant, flexible and understandable code.

Why use CSS classes? We want to keep the same level of specificity, stay flexible and be able to target multiple elements. Element selectors and id selectors do not offer the flexibility that we need.

Let's rewrite our previous example using BEM and keeping specificity low.

/* Low-specificity selector */
.card {}

/* Fixed high-specificity selectors */
.card__title {}

.blogList__image {}

.blogList__title--featured {}

.blogList__img--special {}

You can see how these selectors are simple, understandable and can be easily overridden and extended if needed. And by keeping them low-level (a single class), we are guaranteed optimal performance and flexibility.


DRY Principle

DRY (Don't repeat yourself) principle can be also applied to CSS. Duplicated code in CSS can cause code bloat, unnecessary overrides, reduce maintainability, etc. This issue can be fixed by structuring the code appropriately and having high-quality documentation.

Storybook is a great free tool that enables you to create an overview of available frontend components and write high-quality documentation.

/* Without DRY Princple */
.warningStatus {
  padding: 0.5rem;
  font-weight: bold;
  color: #eba834;
}

.errorStatus {
  padding: 0.5rem;
  font-weight: bold;
  color: #eb3d34;
}

.form-errorStatus {
  padding: 0.5rem 0 0 0;
  font-weight: bold;
  color: #eb3d34;
}

Let's refactor the code so it follows the DRY principle.

/* With DRY Principle */
.status {
  padding: 0.5rem;
  font-weight: bold;
}

.status--warning {
  color: #eba834;
}

.status--error {
  color: #eb3d34;
}

.form__status {
  padding: 0.5rem 0 0 0;
}

Single responsibility principle

By using the single responsibility principle in our CSS, we can ensure that our CSS classes are easily extended and overriden. Let's take a look at the following example.

.button {
  padding: 1rem 2rem;
  font-size: 2rem;
  border-radius: 0.2rem;
  background-color: #eb4934;
  color: #fff;
  font-weight: bold;
}

.button--secondary {
  border-radius: 0;
  font-size: 1rem;
  background-color: #888;
}

We can see that if we want to extend .button class with .button--secondary, we are doing lots of overrides to achieve what we need, when we only want to apply a different background color and keep the default styles.

The problem is that our .button class is having several roles:

 * Sets layout (padding)
 * Sets typography (font-size,font-weight)
 * Sets presentation (color,background-color, border-radius)

this makes our CSS classes very hard to extend and combine with other CSS classes. By keeping this in mind, let's use BEM and OOCSS to improve our CSS.

/* Shared styles */
.button {
  padding: 1rem 2rem;
  font-weight: bold;
  color: #fff;
}

/* Style extensions */
.button--radialBorder {
  border-radius: 0.2rem;
}

.button--large {
  font-size: 2rem;
}

.button--primary{
  background-color: #eb4934;
}

.button--secondary {
  background-color: #888;
}


We have broken down our button styles into several classes that can be used to extend the base button class. We can optionally apply the modifiers and add new ones as the design changes or new elements are being added.


Open/Close principle

software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

We've already used the open/close principle in the previous examples. All new features and options need to be added by extension. Let's take a look at this example.


.card {
  padding: 1rem;
}

.blog-list .card {
  padding: 0.5em 1rem;
}


The .blog-list .card selector has few potential issues:

 * Some styles can be applied only if the .card element is a child of .blog-list element.
 * Styles are forcibly applied to the .card element if placed inside the .blog-list element, which can produce unexpected results and unecessary overrides.

Let's rewrite the previous example:

.card {
  padding: 1rem;
}

.blogList__card {
  padding: 0.5em 1rem;
}


We've fixed the issue by having a single class selector. With this selector, we can avoid unexpected effects and there are no conditional nested styles.


Conclusion

We've seen how by applying these few simple principles we have significantly improved the way we write CSS:

 * Standardized naming and structure, and improved readability by using BEM, OCSS, etc.
 * Improved performance and structure by using low-specificity selectors.
 * Reduced code bloat and improved code quality with DRY principle
 * Flexibility and maintainability by using open/close principle
 * etc.

Thank you for taking the time to read this post. Feel free to share your thoughts about this topic in the comments or drop us an email at hello@prototyp.digital.


Improve your CSS with these 5 principles

Follow this in-depth-guide and learn different ways to optimize images for your website. 

Optimizing images for the web - an in-depth guide - Prototyped

Table Of Contents

 * Calculating JPG image file size
 * Online image optimization
 * Automated solutions
 * Image loading optimization
 * Using CDN
 * WebP image format
 * Optimization for higher pixel density screens
 * Conclusion - Optimization priority

Unoptimized (non-minified) images are one of the main causes of poor website performance, mainly on the initial (first) load. Depending on the resolution and image quality, you might end up with images that take up more than 70% of your total website size.

It's very easy for unoptimized images to end up on a production site and slow down its initial load considerably. Inexperienced devs usually aren't aware of this potential problem. They also aren't aware of a wide range of tools and approaches for optimizing images.

This article aims to cover most of the tools and approaches for optimizing images for the web.


Calculating JPG image file size

The uncompressed image size can be easily calculated by multiplying image width px value with image height px value and multiply the result by 3 bytes which is equivalent to 24 bits (RGB color system). We divide the result by 1,048,576 (1024 \* 1024) to convert the value from bytes to megabytes.

image_size = (image_width * image_height * 3) / 1048576

For example, let's calculate file size for an uncompressed image that has 1366px x 768px dimensions.

1366 * 768 * 3 / 1048576 = 3Mb

Considering that average website size today is between 2Mb and 3Mb, imagine having an image on your site that takes more than 80% the size of your site. 3Mb takes ages to load on slower mobile networks, so you might lose some traffic on your website if the user is waiting for your website to load and most time is spent on loading a single image. Scary thought, isn't it?

So what we can do to avoid having optimized images on the web but preserve the acceptable quality and resolution?


Online image optimization

If you are working on a simple static website that only has a handful of images that won't change often or won't change at all, you can just drag and drop your images in one of the numerous online tools. They do an amazing job at compressing images using various algorithms and are more than enough for simple projects.

Most notable websites, in my opinion, are:

 * Compressor.io - JPG, PNG, SVG, GIF - 1 file at the time
 * Squoosh - JPG, PNG, SVG, GIF - 1 file at the time
 * Optimizilla - JPG and PNG - up to 20 images at the time
 * TinyPNG - JPG and PNG - up to 20 images at the time
 * SVGMinify - SVG - 1 file at the time
 * svgomg - SVG - 1 file at the time


Automated solutions

However, if you are working on more complex projects with multiple people and using a lot of images, optimizing each one as it is added to the project can become tedious. Also, there is a risk that some images may end up not optimized due to human error or some other factor.

On complex projects, it's common to use an equally complex build system like Gulp, Webpack, Parcel, etc. Image optimization plugins can be easily added to those build configs and fully automate the image optimization process. Images can be optimized as soon as they are added to the project.

Most notable plugin, in my opinion, is imagemin which can be easily integrated with any CLI or build tools:

 * imagemin - CLI
 * imagemin - Gulp
 * imagemin - Webpack
 * imagemin - Parcel


Image loading optimization

We've looked at the image optimization strategies that reduce the file size by compressing the image without changing the image resolution and affecting image quality too much. Although optimizing image file reduces the file size of images considerably, having multiple optimized images (on the webshop catalog page for example) loaded all at once can have a poor effect on performance.


Lazy Loading

Lazy loading is a concept of only loading assets that are needed. In our case, only images that are currently within the user's viewport (screen) are loaded. Other images are not loaded until they appear within the user's viewport.

Although native Lazy loading has just been recently introduced to browsers, there have been many JavaScript-based solutions available.

Native Lazy Loading

<img src="image.jpg" loading="lazy" alt="Sample image" />

JavaScript-based solutions

Most notable JavaScript-based solutions, in my opinion, are:

 * verlok/lazyload
 * yall.js
 * Blazy (not actively maintained)


Progressive images

Although lazy loading does a great job performance-wise, looking at the problem from UX perspective we can see that the user is waiting for the image to load and looking at the blank space. On slow connections, downloading images can take ages. This is where progressive images come into play.

Basically, having a progressive image means that a low-quality image will be displayed to the user until a high-quality image has finished loading. A low-quality image has a considerably smaller file size due to the low quality and high compression rate, so this image will be loaded very fast. In between the low quality and high-quality image we can have as many images with varying quality as we need and we can load the higher quality image on each download.

Similarly to the article on Skeleton loading I've written, this technique gives the user an illusion of speed. User is looking at an image that is loading and becoming more clearer as it loads higher and higher quality image, instead of looking at the empty space waiting for something to happen.

This is an JavaScript implementation of progressive images: progressive-image


Responsive images

We also need to be careful of using properly-sized images.

For example, let's say we have an image that is 1920px maximum width on desktop , 1024px maximum width on tablet devices and 568px maximum width on mobile devices. Simplest solution would be to just use the 1920px image and cover all the cases, right? In that case, an user on a smartphone with slow and unreliable connection would have to wait ages for the massive image to download and we'd be back at the square one of the problem.

Luckily for us, we can use picture element to tell the browser which image to dowload, depending on the media query. Although this element is supported by more than 93% of globally used browsers, it has a pretty simple fallback with img element already inside it.

<picture>
  <source media="(min-width: 1025px)" srcset="image_desktop.jpg">
  <source media="(min-width: 769px)" srcset="image_tablet.jpg">
  <img src="image_mobile.jpg" alt="Sample image">
</picture> 


Using CDN

CDN services like Cloudinary and Cloudflare can perform image optimization on the server and serve the optimized images to the user. If your website uses a CDN, it's worth looking into asset optimization options. This allows us not to worry about image quality optimization at all, and have all optimizations done server-side. We only need to look into optimizing image loading by either using lazy loading or progressive images.


WebP image format

WebP image format is developed by Google and is an image format specifically optimized for the web. According to the canIUse data, current browser support for WebP image format is at around 80% which is great. Luckily, implementing a fallback to standard jpg image with img element inside picture element is easy.

<picture>
  <source type="image/webp" srcset="image.webp" />
  <source srcset="image.jpg" />
  <img src="image.jpg" alt="Sample image" />
</picture>

Although there are numerous online file format converters that can convert images to WebP format, CDN services can easily perform format conversion server-side.


Optimization for high pixel density screens

This is more UX improvement rather than performance, but it's also important to take into account devices that have higher pixel density.

For example, let's assume that we are displaying an 768px x 320px banner image on 768px screen. But the screen has 2x density and the px width is actally: 2 x 768 = 1536px. Basically, we are stretching 768px over 1536px and this leads to blurry image on high pixel density devices.

In order to fix that, we need to serve an image optimized for high pixel density screens. We need to create separate images that are 2 times or 3 times the resolution of regular screens and use the srcset attribute with 2x tag marking for higher resolution image.

<img src="image-1x.jpg" srcset="image-2x.jpg 2x" alt="Sample image" /> 


Example - Responsive WebP/PNG images with high-density screen support

<picture>
    <source srcset="./images/webp/hero-image-420-min.webp 1x, ./images/webp/hero-image-760-min.webp 2x" type="image/webp" media="(max-width: 440px)">
    <source srcset="./images/minified/hero-image-420-min.png 1x, ./images/minified/hero-image-760-min.png 2x" media="(max-width: 440px)">
    <source srcset="./images/webp/hero-image-550-min.webp 1x, ./images/webp/hero-image-960-min.webp 2x" type="image/webp" media="(max-width: 767px)">
    <source srcset="./images/minified/hero-image-550-min.png 1x, ./images/minified/hero-image-960-min.png 2x" media="(max-width: 767px)">
    <source srcset="./images/webp/hero-image-420-min.webp 1x, ./images/webp/hero-image-760-min.webp 2x" type="image/webp" media="(max-width: 1023px)">
    <source srcset="./images/minified/hero-image-420-min.png 1x, ./images/minified/hero-image-760-min.png 2x" media="(max-width: 1023px)">
    <source srcset="./images/webp/hero-image-760-min.webp 1x, ./images/webp/hero-image-960-min.webp 2x" type="image/webp" media="(max-width: 1919px)">
    <source srcset="./images/minified/hero-image-760-min.png 1x, ./images/minified/hero-image-960-min.png 2x" media="(max-width: 1919px)">
    <source srcset="./images/webp/hero-image-960-min.webp" type="image/webp">
    <source srcset="./images/minified/hero-image-960-min.png">
    <img  src="./images/minified/hero-image-960-min.png" alt="Example">
</picture>


Conclusion - Optimization priority

 1. Use optimized images (optimized by automated build tools, online services or CDN)
 2. Use lazy loading (JS solution until native becomes more supported)
 3. Optimize images for high pixel density screens
 4. Use WebP image format
 5. Use progressive images

Optional: Remember to serve images (and other static assets) over CDN if you are able to.



Thank you for taking the time to read this post. Feel free to share your thoughts about this topic in the comments or drop us an email at hello@prototyp.digital.

Optimizing images for the web - an in-depth guide

Learn when it is a good idea to use Skeleton Loading and how to implement it in React.

Implementing Skeleton Loading in React - Prototyped

The idea and concept of Skeleton Loading or Skeleton Screens was introduced in 2013. in this blog post by Luke Wroblewski. It describes the concept of a blank screen where dynamic content is replaced by styled blocks (skeleton) and is replaced with real content once it's finished loading.




Skeleton loading is better than a spinner

When a user looks at the page with a standard loading spinner, they're thinking "I'm waiting for it to load". We're making the user watch a dull repeating animation and the user feels like it's staring at the clock.

When a user looks at the page with skeleton loading or skeleton screen, they're thinking "It's almost loaded, something is happening". The user is watching a page that seems like it's right about to finish loading. User is watching at a page that is not empty or dull, even though we haven't loaded any content yet. It gives an illusion of speed.

But there is something to keep in mind about skeleton loading...


Skeleton loading is used when the final loaded state is predictable

We cannot simply replace every dynamically loaded element on the page with skeleton loading. In some cases, we cannot predict how the final loaded state of the page is going to look like.

For example, if we try and assume a final state of the page (let's say we chose 1 out of 4 wildly different possible states) and create a skeleton screen based on our assumption. When a user looks at the skeleton and the loaded content wildly differs from the skeleton, the transition looks very out of place and jarring. This may hurt the UX and make your app feel chaotic.

Let's assume we're looking at an eCommerce site and we are looking at the homepage. eCommerce homepages often change their look and layout, depending on the events or sales that are going on. It wouldn't be a good idea to implement the skeleton loading here.

Looking at the catalog page, where products are displayed in 4-column layout, with 24 items per page. We can safely assume that this state is not going to change. Even if we finally load 12 or 15 products, instead of assumed 24 the transition remains smooth. Catalog page loading is also very load-intensive (if pagination, sorting, and filters are used) so skeleton loading may also help in keeping the users on the page even in cases when loading times are larger than expected.


Implementing Skeleton loading in React

In the following example, we are implementing a skeleton loading for the food recipe card component. This is how the component looks like.

import * as React from 'react';
import { Link } from 'react-router-dom';
import { LazyImage } from 'components';
import { getUri } from 'util/getUri';

export const RecipeCard = ({
  calories,
  ingredients,
  image,
  label,
  source,
  uri
}) => {
  return (
    <li className="recipeCard">
      <Link className="recipeCard__link" to={`/recipes/recipe/${getUri(uri)}`}>
        <LazyImage className="recipeCard__image" src={image} alt={label} />
        <div className="recipeCard__wrapper">
          <div>
            <h3 className="recipeCard__title">{label}</h3>
            <p className="paragraph">
              <strong>
                By <span className="gradient--text">{source}</span>
              </strong>
            </p>
          </div>

          <div className="recipeCard__info">
            <strong className="gradient--text">{Math.ceil(calories)}</strong>{' '}
            calories |{' '}
            <strong className="gradient--text">{ingredients.length}</strong>{' '}
            ingredients
          </div>
        </div>
      </Link>
    </li>
  );
};



This is a simple skeleton that doesn't use any animations, just a plain color which also looks fine. You can easily add the animation by animating the background gradient.

First, we need to set up the styles for our skeleton components. We are setting up our base skeleton styles in .recipeCard__skeleton class. We are setting inline-block to mimic content behavior (like alignment), we use padding to add height (equal to 1 unit of line-height, in this case) to an element. We also have two modifier classes that change the width of the content and additional class for an image that has aspect ratio 1:1 (this is why padding is set to 100%).



.recipeCard__skeleton {
    display: inline-block;
    background-color: var(--color__gray--lighter);
    padding-bottom: var(--spacing__vertical--1);
}

.recipeCard__skeleton--medium {
    width: 33%;
}

.recipeCard__skeleton--large {
    width: 100%;
}
.recipeCard__image--skeleton {
    padding-bottom: 100%;
    background-color: var(--color__gray--lighter);
}



Let's create our Skeleton component:

 1. Copy the content of the "real" component and paste it into the Skeleton component. Change the const name and export.
 2. Replace all dynamic content (coming from props) to skeleton elements. Spans work fine due to them not having any default styles. Let the layout styles and grids handle everything else and keep the skeletons in place.
 3. Conditionally load the skeleton in the main component



import * as React from 'react';
import { Link } from 'react-router-dom';

export const Skeleton = () => {
  return (
    <li className="recipeCard">
      <div className="recipeCard__link">
        <div className="recipeCard__image--skeleton" />
        <div className="recipeCard__wrapper">
          <div>
            <h3 className="recipeCard__title">
              <span className="recipeCard__skeleton recipeCard__skeleton--large"></span>
            </h3>
            <p className="paragraph">
              <span className="recipeCard__skeleton recipeCard__skeleton--large"></span>
            </p>
          </div>

          <div className="recipeCard__info">
            <span className="recipeCard__skeleton recipeCard__skeleton--medium"></span>{' '}
            <span className="recipeCard__skeleton recipeCard__skeleton--medium"></span>
          </div>
        </div>
      </div>
    </li>
  );
};




And this is how the final component will look like.



Pretty simple, right? Once you get a hang of replacing the content with skeletons, you can set up a very versatile library of classes for replacing skeleton content and create the skeleton screens really quickly.

Thank you for taking the time to read this post. Feel free to share your thoughts about this topic in the comments or drop us an email at hello@prototyp.digital.

Implementing Skeleton Loading in React

Discover the best practices and learn how to establish a solid pattern for building custom React hooks.

Building Custom React Hooks - Prototyped

React hooks simplify the process of creating reusable, clean and versatile code, and advanced optimization techniques like memoization are now more accessible and easier to use. React’s official documentation doesn’t cover custom hooks in detail as it covers the basic hooks, so the focus of this article is going to be primarily on building custom React hooks and best practices.

Understanding basic React hooks are required to get the most out of this article. If you aren’t already familiar with the basics, there are numerous great articles out there covering them. For example, React’s official docs are a great place to start.


Mindset

In order to build a versatile, performant and reusable custom hook, there are several things to keep in mind.


Hooks run each time component re-renders

Since we’re working with functional components and hooks, we no longer have the need for lifecycle methods. Each time state or a prop is changed, the functional component is being re-rendered and, thusly, our custom hook is being called over and over again.


Use basic hooks as much as possible

Basic React hooks are the core of any custom hook. We can use memoization and hook dependency arrays to control which parts of our custom hook will change or will not change with each re-render. It’s important to understand the role each basic hook can have in our custom hook in order to use them effectively and build performant hooks.


Rules of hooks

There are a few important rules to keep in mind. These rules are explained in detail on React hooks documentation.


Building the custom hook

Now that we have covered the basics, we’re ready to build our own custom hook. In the following example, we’ll establish a solid pattern for building custom hooks and go through some of the best practices.

Let’s imagine that we’re working on a project where users can play multiple games that use dice rolls as part of their game mechanic. Some games require only a single dice to play and some games may require multiple dice to play. We’ll also assume that during some games, the number of dice used may change.

Keeping that in mind, we are going to build useGameDice hook with the following features:

 * The custom hook can be initialized with a number of dice being used and an initial value
 * A function that sets the number of dice being used
 * A function that rolls the dice. Returns an array of random numbers between 1 and 6. Length is determined by the number of dice being used
 * A function that resets all dice values to initial value


Setting up the hook (imports and hook function)

We are declaring our custom hook as a regular arrow function using the recommended convention of naming custom hooks — the name should start with the “use” keyword. We are also importing React hooks that we’ll use later on in our implementation. We could also import constants, other functions, other custom hooks, etc.

Our hook can be initialized with 2 optional variables:

 * initialNumberOfDice — how many dice will be used
 * initialDiceValue — determines the initial value and value after reset

Both variables have a default value of 1 to avoid any errors and simplify the hook setup.



import { useState, useMemo, useCallback, useEffect } from "react";

export const useGameDice = (initialNumberOfDice = 1, initialDiceValue = 1) => {
     /* We’ll be adding code here in order */
};


Adding state and memoized private variables

First, we need to set up our state. We’ll declare two simple states:

 * diceValue — array which size is defined by numberOfDice and holds value for each dice
 * numberOfDice — determines the number of dice (diceValue array size) that will be used

We are also initializing initialDiceState variable that creates the initial array value that will be assigned on initial render and state reset. This value is memoized to avoid array being initialized and filled with default values on each re-render.



const [diceValue, setDiceValue] = useState();
const [numberOfDice, setNumberOfDice] = useState(initialNumberOfDice);

const initalDiceState = useMemo(
  () => Array(numberOfDice).fill(initialDiceValue),
  [numberOfDice, initialDiceValue]
);


Adding memoized hook functions

Next, we’ll create the following functions:

 * generateRandomDiceNumber — generates a random number between 1 and 6 (a single dice roll)
 * rollDice — calls a random number generator for each element in the array (dice)
 * resetDice — resets the dice value state to an initial value



const generateRandomDiceNumber = useCallback(() => {
  return Math.floor(Math.random() * 6) + 1;
}, []);

const rollDice = useCallback(() => {
  const arrayConfig = { length: numberOfDice };
  const newDiceValues = Array.from(arrayConfig, generateRandomDiceNumber);
  setDiceValue(newDiceValues);
}, [numberOfDice, generateRandomDiceNumber]);

const resetDice = useCallback(() => {
  setDiceValue(initalDiceState);
}, [initalDiceState]);



We are using useCallback hook to control when the functions are going to be re-initialized. Functions are re-initialized only when any variable in their dependency array changes. In the case of the generateRandomDiceNumber function, it’s never re-initialized after the first render and initialization because this function doesn’t depend on any external variable or state.


Adding side effects — hook initialization & update

We need to set up a listener that will watch for updates to our initial dice state. This side effect has two responsibilities:

 1. It sets the dice state to the initial value when the hook is first initialized
 2. It updates the dice state to the initial value when dice number (array size) has changed



useEffect(() => {
   setDiceValue(initalDiceState);
 }, [initalDiceState]);


API setup & return statement

Finally, we are defining our state and api objects and returning them in an array, following the useState convention. Let’s take a look at each object:

 * state — holds all our state values. We expect this object to change on almost every re-render
 * api — holds all functions. We are returning some of our functions declared in useCallback and a function from useState hook. This object is memoized because we do not expect this to change on almost every re-render



const state = {
   diceValue,
   numberOfDice
 };

const api = useMemo(
   () => ({
     setNumberOfDice,
     rollDice,
     resetDice
   }),
   [setNumberOfDice, rollDice, resetDice]
 );

 return [state, api];



We are returning the objects in an array because we want this hook to be flexible. By doing so, we allow developers to rename the returned variables and allow them to initialize multiple instances of this hook if needed.



const [diceFirst_state, diceFirst_api] = useGameDice();
const [diceSecond_state, diceSecond_api] = useGameDice();


Git repository & demo

You can see the final implementation and full code with a demo on the following GitHub repository.


React custom hooks pattern overview

By now, you might have noticed that we grouped the code we were adding in sections. This structured and clean pattern follows a logical path:

 1. State initialization (useState, useReducer), local variables initialization (useMemo), ref initialization (useRef) & external custom hooks initialization
 2. Memoized functions (useCallback)
 3. Side effects (useEffect)
 4. API setup (state and memoized API)
 5. Return statement


Conclusion

It’s no surprise that hooks were well received by React community. Developers are able to share logic between components more easily, create multiple components (interfaces) for each custom hook, pick and choose the parts of hook’s state and API they’ll use in their components, etc.

This reusability and versatility make hooks a real game-changer in React app development. With an established pattern and best practices when building custom React hooks, developers are able to deliver code with consistent quality, clear structure, and optimal performance.

Thank you for taking the time to read the article. If you’ve found it helpful, please give this article a clap and share it.

Building Custom React Hooks

Find out what code snippet is useful for destructuring variables with default values (if the value is undefined).

Javascript ES6: Destructuring with default values - Prototyped

This is a short, but very useful code snippet for destructuring variables with default values (if the value is undefined). Very useful snippet for avoiding errors caused by undefined variables.

In the following example, the options object is being destructured.

const {
    valFirst = 1,
    valSecond = "hello",
    valThird = false
  } = options;



If a destructured value doesn't exist within the object, it will be assigned a default value. If it does exist within the object, it will be assigned the value from the object.

Thank you for taking the time to read this post. Feel free to share your thoughts about this topic in the comments or drop us an email at hello@prototyp.digital.

Javascript ES6: Destructuring with default values

Find out how to reduce the amount of code, simplify the code and allow for multiple React's useEffect hooks to be called in a single component.

React: useEffect explained with lifecycle methods - Prototyped 

React's useEffect hook combines componentDidMount, componentDidUpdate and componentWillUnmount lifecycle methods. This is very useful for the following reasons: it reduces the amount of code, simplifies the code and allows for multiple useEffect hooks to be called in a single component.

You can read more about the useEffect hook here: React docs

Sometimes, we'd like only a single of those lifecycle methods to run. The following cheat-sheet will help you achieve the "effect" you're looking for.


componentDidMount equivalent

In order to have this hook run only once (when a component is mounted), we need to set an empty array as a hook dependency.

useEffect(() => {
  /* ComponentDidMount code */
}, []);


componentDidUpdate equivalent

In order to have this hook run when the component is updated (this includes mounting), we need to set at least one variable as hook's dependency (in this case, var1 and var2).

useEffect(() => {
  /* componentDidUpdate code */
}, [var1, var2]);


componentWillUnmount equivalent

In order to have this hook run when the component is unmounted, we need to return a function from the hook. If we want cleanup function to run only when component has unmounted, we need to set an empty array. If we set one or more variables in the dependency array, cleanup will run at every re-render.

useEffect(() => {
  return () => {
   /* componentWillUnmount code */
  }
}, []);


All three combined

useEffect(() => {

  /* componentDidMount code + componentDidUpdate code */

  return () => {
   /* componentWillUnmount code */
  }
}, [var1, var2]);



Thank you for taking the time to read this post. Feel free to share your thoughts about this topic in the comments or drop us an email at hello@prototyp.digital.

AuthorAdrian Bece

Start a Project