"Looking into best practices for optimizing for perceived performance. Facebooks skeleton loading for example. Who knows about some great cases?"
Let's start with some abbreviations:
- UX: User eXperience
How is a user experiencing an environment (within this subject, how will users experience the loading process);
- SSR: Server Side Rendered
A webpage is Server Side Rendered when its content (in HTML) is being rendered on the server, and contents are being output within the initial HTML document;
- CSR: Client Side Rendered
- PWA: Progressive Web App
- AMP: Accelerated Mobile Pages.
Perceived performance within CSR
Skeleton loading could be a solution when practicing Client Side Rendering. However, downsides to be aware of when developing sites or e-commerce while building the CSR way, are as following:
- Setting up skeleton loading might take more development time (as you are building some kind of equivalent instead of a derivation of the eventual page);
- Content placement or positioning might be different after fully loaded. Content may be larger than skeleton loading is illustrating. As a result, skeleton loading might produce false expectations as to where content might pop up.
- Skeleton loading often results in layout shifts (CLS metric);
- Visitor can't grasp the page's content (title, image, text) directly as it isn't meaningful, not enforcing visitor's to "answering your needs, encouraging their next action to remain with you". This may have an decreasing impact on the conversion rate;
- Users of old(er) devices / browsers, or slow internet (bad coverage, low internet plan) might be looking at skeleton loading for a (relative) long period of time.
CSR skeleton loading example
Below, you are seeing a screenshot of a before and after situation within a client side rendered webpage. Click on the image to see the large image.
UX, SEO and inclusivity
Perceived performance within SSR
When your webpages are being rendered server side (SSR), there is no need to apply skeleton loading. Why would you serve a skeleton loading interface when the main content is already there, within the initial downloaded HTML document? A best practice would be to inline CSS partially. For example, this is also done within AMP solutions, although coming with restrictions.
SSR perceived performance example
Below, you are seeing a screenshot of a before and after situation within a server side rendered webpage, with the advantage that the meaningful content is already there when first bytes are received by the browser.
Wordpress and inline CSS
There are also Wordpress plugins to inline CSS for you, but this may produce downsides:
- browser caching advantages aren't utilized;
- this often result in layout shifts (once again, CLS metric);
- initial download-size will increase, making the initial load time slower. For example, DeOnlineDrogist.nl productpages increased 633% in HTML download-size while inlining CSS.
Your visitors can start reading right away
But skeleton loading looks shiny
At the agency I work, we apply perceived performance too, automated within the Content Management System we use. One might not notice, as content will be visible as soon as the first bytes were received by the browser. At the time the user starts interacting with a site, other resources might already be loaded while navigating the website of webshop won't be blocked at all.
Obviously, creating skeleton loading might be more fun for developer experience, but the art is to improve user experience.
Want to know more about implementation? I will be talking about this specific subject during the next Refresh event (Tuesday, November 26th @ Groningen).
Skeleton loading best practice
If you already build your website or shop the CSR way and want to improve the perceived performance, than do read the article on skeleton screens and perceived duration while waiting. The conclusion? You are better of using skeleton loading instead of a loading spinner. Within skeleton loading, slow left to right wave animation seems to be best for perceived duration (amongst 20 testers):
Do take note of the fact that this research was done in a pre-defined environment. There were no real-life influences such as:
- Internet-speed fluctuations;
- JS preferences (noscript/saveData);
- JS compatibility issues due to operating system of browser version;
- Device capabilities (memory, CPU).