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.

Top two font plugins for GatsbyAnd if we open any of those two, we are greeted
by the following message and README .

Oh no... this isn't goodMost-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.Adrian BecePrototyped - Thoughts from the folks at PROTOTYP
[/improving-website-performance-by-eliminating-render-blocking-css-and-javascript/]
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.

This isn't all that bad considering the performance gain, but it is very
noticeableWhat 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.

We've adjusted the style (line-height, letter spacing, word spacing) of fallback
font and the change looks nicerYou 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 [https://www.gatsbyjs.com/plugins/gatsby-omni-font-loader/] 
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
[https://csswizardry.com/2020/05/the-fastest-google-fonts/] and enable devs to
handle FOUT easily.

And few days ago, I've published Gatsby Omni Font Loader
[https://www.gatsbyjs.com/plugins/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
[https://github.com/codeAdrian/gatsby-omni-font-loader]. 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
& FOUC with font loading status watcher. Supports both local-host...
codeAdrianGitHub [https://github.com/codeAdrian/gatsby-omni-font-loader]
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 [https://meowni.ca/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 [https://codeadrian.github.io/] 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.Adrian BecePrototyped - Thoughts from the folks at PROTOTYP
[/best-way-to-lazy-load-images-for-maximum-performance/]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>

Critical CSS on my personal siteThis 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. 

Non-critical styles being loaded on a below-the-fold content. Notice how some
(critical) styles are already applied (grey background) before the rest is
loaded (non-critical)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
[https://bugzilla.mozilla.org/show_bug.cgi?id=1405761] 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
[https://caniuse.com/#search=loading] 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 [https://github.com/aFarkas/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
[https://github.com/aFarkas/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 [https://codeadrian.github.io/] 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.
Adrian BecePrototyped - Thoughts from the folks at PROTOTYP
[/optimizing-images-for-the-web-an-in-depth-guide/]

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.

Example of stored payment method on Magento 2 demoWith 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.)

Standard webshop navigation with branding, categories, cart, account and helpful
link elementsLooking 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.

Example of a prominent CTA button on Tata CliqExample of a prominent CTA button
on New ChapterCTA 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. 

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

 * Schema.org schemas [https://schema.org/docs/schemas.html]
 * How to use schema.org for eCommerce websites
   [https://www.osiaffiliate.com/blog/how-to-use-schema-org-for-ecommerce-websites/]
 * Understand how structured data works
   [https://developers.google.com/search/docs/guides/intro-structured-data]

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.

Converse category pageFrom 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.

Harry’s landing page — notice the headerAnd 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.

Harry’s checkout — notice how the header is simplifiedWe 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.

Users can fill out multi-column forms in different waysThis 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.

Prominent validation as soon as input loses focusAdditionally, 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
[https://www.toptal.com/designers/e-commerce/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.

The full pixel pipeline (from Google Developers site)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 [https://csscompressor.com/] - simple online minification
 * CSSNano [https://github.com/cssnano/cssnano] - Automated CSS optimizer +
   minifier
 * Clean CSS [https://github.com/jakubpawlowicz/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 [https://github.com/cssnano/cssnano] - Automated CSS optimizer +
   minifier
 * Clean CSS [https://github.com/jakubpawlowicz/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
[https://css-tricks.com/brotli-static-compression/] 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 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…Adrian BecePrototyped - Thoughts from the folks at
PROTOTYP [/improve-your-css-with-these-5-principles/]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 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…Adrian BecePrototyped - Thoughts from the folks at
PROTOTYP [/improve-your-css-with-these-5-principles/]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)
[https://en.bem.info/methodology/], SMACSS (Scalable and Modular Architecture
for CSS) [http://smacss.com/] and OOCSS (Object Oriented CSS)
[https://www.smashingmagazine.com/2011/12/an-introduction-to-object-oriented-css-oocss/] 
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 [https://storybook.js.org/] 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
   [https://compressor.io/]
 * Squoosh - JPG, PNG, SVG, GIF - 1 file at the time [https://squoosh.app/]
 * Optimizilla - JPG and PNG - up to 20 images at the time
   [https://imagecompressor.com/]
 * TinyPNG - JPG and PNG - up to 20 images at the time [https://tinypng.com/]
 * SVGMinify - SVG - 1 file at the time [https://www.svgminify.com/]
 * svgomg - SVG - 1 file at the time [https://jakearchibald.github.io/svgomg/]

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
[https://www.npmjs.com/package/imagemin] which can be easily integrated with any
CLI or build tools:

 * imagemin - CLI [https://github.com/imagemin/imagemin-cli]
 * imagemin - Gulp [https://github.com/sindresorhus/gulp-imagemin]
 * imagemin - Webpack [https://github.com/itgalaxy/imagemin-webpack]
 * imagemin - Parcel [https://github.com/DeMoorJasper/parcel-plugin-imagemin]

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 [https://github.com/verlok/lazyload]
 * yall.js [https://github.com/malchata/yall.js/]
 * Blazy (not actively maintained) [https://github.com/dinbror/blazy]

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
[https://www.npmjs.com/package/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
[https://www.lukew.com/ff/entry.asp?1797]. 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
[https://reactjs.org/docs/hooks-intro.html] 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 [https://reactjs.org/docs/hooks-rules.html].

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 [https://github.com/codeAdrian/dice-app].

A simple app built with the useGameDice hookReact 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
[https://reactjs.org/docs/hooks-effect.html]

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