Forem: Simon Wicki

The Duality of CLS with Lazy Loading Components

Simon Wicki — Mon, 28 Mar 2022 06:29:15 +0000

When you optimise your web app, your goal is to make the experience better for the user: That means usually 'faster' by transferring and parsing less data. But caution: The same web app can cause Cumulative Layout Shift (CLS) on slower connections but runs without CLS on faster connection.

If you'd like a refresher about Core Web Vitals, I explained them with GIFs in this post.

TL;DR: slower connections can result in CLS when lazy loading components that you wouldn't see on wifi connections.

Either don't lazy load the component at all or await for the js file to be loaded and mounted.

The Duality

We assume that a web app loads the same on slower connections, just slower. Unfortunately that's not always the case with lazy loadable components.

With lazy loadable components we deal with two asyncnesses:

async API responses (JSON)
async lazy loading components (JS)

What if the API responses (1) are faster than the dynamically loaded JS (2)? What if you lazy load a component that sits in the middle of your web content? The answer to these questions you see in the screencapture above: Google will punish you with CLS.

CLS measurement

I've seen a lot of confusion about Core Web Vitals, especially CLS.

Unlike other Core Web Vitals, CLS is continuously measured and cumulatively added to the score. For a classic SPA web app this means that Google will keep the CLS score on a per-route basis.

CLS has the following characteristics:

After each route change, the CLS resets to 0
After any user interaction, you get a grace period of 500ms where CLS is not taken into account

Measurements by real users: Chrome users send Core Web Vitals metrics to Google directly. It's not a Googlebot that captures these metrics while crawling the site.

These real user measurements are collected as Field Data and flow into Google's CrUX report.

That means you need to take the real world into account:

If you have a lot of traffic from India, but your servers are on the other end of the world, that your LCP (Largest Contentful Paint) will probably suffer.
If you have a lot of traffic from China, it's likely that some services are blocked by Chinese ISPs and won't load. This could cause unwanted CLS within your content.

Solutions

We need to be in full control of what to display to the user at what time. With duality in mind, we need to know the following:

are API requests still loading?
are async components components still loading?

A skeleton loader is an ideal way to wait until both, API requests and async components, are ready.

Solution #1: Don't lazy load components at all

The quickest and least error prone solution would be to pass on lazy loading components. In most cases the saved kilobytes through lazy loading doesn't justify the CLS that it might cause. If your performance budget allows it, go with this solution.

Let's assume we have a web app with 10% logged-in users.

function render() {
    // not all users require to download and render HugeComponent
    if (isLoggedIn) {
        return <HugeComponent />;
    }
}

Without code splitting we'd send the JS of <HugeComponent> to 90% of the users that don't need it. This can affect LCP and FID.

With code splitting we'd pack the JS of <HugeComponent> into the additional-comps.js chunk and only send it over the wire when it's needed.

// without code splitting
import HugeComponent from '@/components/HugeComponent';

// with code splitting
const HugeComponent = () => (await import(
    /* webpackChunkName: "additional-comps" */ 
    '@/components/HugeComponent')
).default;

There are two criterias that help you decide if you should lazy load a component or not:

size of
how often would be rendered for users

If you come to the conclusion that your performance budget is tight and you need to lazy load the component, see solution #2.

Solution #2: Await loading and mounting of component

If your component isn't used for the majority of users and it would increase the bundle by a lot, have a look at this solution.

Wait for async components to be lazily loaded and mounted can be tricky. You need to render the component but the mounting happens later. Here's a gist of how it could be done.

function Parent({ isLoggedIn }) {
    const [isLoading, setLoading] = useState(false);
    // important: only hide the children with display: none.
    // if we used if-else, we'd never load the lazy loadable component;
    // and then we'd never change isLoading with its callback.
    const styles = { display: isLoading ? 'none' : 'block' };

    return (
        {/* HugeComponent is lazy loaded, because not all users will need it */}
        (isLoggedIn && <HugeComponent 
            style={ styles } 
            mounted={() => setLoading(true)}
        />)

        {/* display skeleton element for time of loading */}
        (isLoading && <div className="skeleton-loader"></div>)
    );
}


function HugeComponent(props: { mounted: () => void }) {
    const [dataA, setData] = useState(null);

    useEffect(async () => {
        const result = await lib.request();
        setData(result);
        // tell the parent component that everything is ready to be fully rendered
        props.mounted();
    }, []);

    return (/* ... */);
}

If we didn't use display: hidden for the loading state on the <HugeComponent>, we'd never trigger the loading of the async component. Thus, Line 28 would never be reached and the isLoading state would stay on false forever.

Conclusion

When you lost green URLs in the Google Search Console due to CLS and you can't reproduce it yourself, try debugging your web app with a slower connection.

So if you're using lazy loadable components, chances are high that might be a victim of the duality of CLS.

Sued by Using Google Fonts: Data Privacy and GDPR

Simon Wicki — Tue, 22 Feb 2022 09:59:49 +0000

The German court has ruled last month that Google Fonts is not in compliance with GDPR.

The integration of dynamic web content such as Google Fonts from US web services is illegal without the consent of the visitor.

A website operator received a fine of 100€. The Munich court clearly wanted to set an example. They even mentioned the next fine will be 250.000€ for the website operator if they don't comply.

Data protection authorities (DPA) in other EU countries became all ears. It's likely to see more rulings and enforcements of this in the name of GDPR.

In this post I want to show why you should care, even if you're not from Germany.

How Google Fonts collects personal data

When a user wants to load a font via Google Fonts, it uses 2 types of requests:

Dynamic request: fonts.googleapis.com/css2?family={font}
Asset request(s): fonts.gstatic.com/s/{font}/...

The dynamic request is the reason of the German court's ruling: The user's IP address is shared with Google Fonts. This is object to personally identifiable information (PII).

From the Google Fonts FAQ we get a fuzzy idea of what is going on:

Google Fonts logs records of the CSS and the font file requests, and access to this data is kept secure.

Are they logging user's IP addresses along other fingerprinting PIIs?
Are they using these records to fill the gaps of a user's internet journey?

What we know is that they collect and store end-user data to be able to—what they state as needed to "serve fonts efficiently".

"I'm running Google Fonts, what are my options?"

From a GDPR point of view you have 2 options:

Host the fonts locally: You can already download them from the Google Fonts website directly.
Keep using it and ask your users for consent: Because of the data transfer to Google you're required to ask your users for their consent. Implement a Consent Banner where Google Fonts is stated as one of the Data Processing Services (DPS). On top, you need to await your user's consent before requesting the Google Font service. Postponing font files is inherently not ideal.

Just ask yourself if the additional value of Google Fonts' convenience is worth it to pay the price for data privacy.

Why you should care

When tech companies get enough data points to connect the dots they get a pretty good picture of what you do on the internet. This data is usually used for personalised advertisement. I could live with this if it was the user’s only drawback of personal data collection.

Google Fonts is one of these data points that helps connecting further puzzle pieces together.

Besides the advertisement aspect, it’s problematic because of:

the lack of control over your personal data
leaving a profile on tech companies' servers that can be accessed under certain requirements by the US authorities
being on the internet where data leaks and hacks happen very often

Currently it’s up to us developers to protect the end-user. This is why you should care.

Closing words

I hope I could shed some light on why Google Fonts is data privacy concern.

Also: I am not a lawyer.

An Ode to AngularJS

Simon Wicki — Wed, 19 Jan 2022 09:14:26 +0000

In remembrance of my first love.

Your LTS came finally to an end. You retired on 31st December 2021. You will always have a special place in my heart.

You arrived with great anticipation,
    Put the web dev world upside down;
Model, View and Controller were in separation,
    Even Javascript beginners didn’t frown.

Be it JavaScript, CoffeeScript or SCSS,
    You handled them all in a snap;
Grunt helped you to transpile and compress,
    The only thing needed was an ng-app.

You were patient with faulty code,
    Throwing errors with the where and why;
Did selectors return a wrong DOM node?
    Did watchers kill the CPU workload?
        Did a variable on $scope get overshadowed?
Maybe the external callback needs an $apply!
    Maybe $inject lacks used params to minify!
        Maybe avoid $rootScope for all events passing by!

You were either praised or attacked,
    Yet, you advanced and left doubters behind;
Daily flame wars you fought against react,
    Until the day window.angular became undefined.

If you found this post interesting please leave a ❤️ on this tweet and consider following my 🎢 journey about #webperf, #buildinpublic, #nonfiction books and #frontend things on Twitter.

Simon Wicki

@zwacky

An Ode to AngularJS

You arrived with great anticipation,
Put the web dev world upside down;
Model, View and Controller were in separation,
Even Javascript beginners didn’t frown.

10:18 AM - 19 Jan 2022

How does your company approach mentorship?

Simon Wicki — Fri, 07 Jan 2022 14:31:40 +0000

How did you get there?
How did you form the best mentorship model?
Are there any frameworks that can be implemented like agile?

Simon Wicki

@zwacky

How does your company approach mentorship? #devcommunity

14:29 PM - 07 Jan 2022

Interface vs Type Alias in TypeScript—Quick Comparison

Simon Wicki — Fri, 07 Jan 2022 07:56:22 +0000

This can be confusing for anyone working with TypeScript—beginner or seasoned programmer. Both ways can cover similar needs.

In this post you’ll quickly see what Typescript feature is possible to implement as Type Alias or Interface. I stayed brief and spicy to give the post an overview character.

👉 TLDR: You don’t care about each difference? What should you use?

Use interface until you need type
—orta

Overview: Interface (I) vs Type Alias (T)

Feature	I	T	Example
Primitives	❌	✅	`type UUID = string`
Extend / Intersect	✅	✅	`Response & ErrorHandling`
Unions	❌	✅	`string \| number`
Mapped object types	❌	✅	`['apple' \| 'orange']: number`
Augment existing types	✅	❌	`declare global { interface Window { … } }`
Declare type with typeof	❌	✅	`Response = typeof ReturnType<fetch>`
Tuples	✅	✅	`[string, number]`
Functions	✅	✅	`(x: number, y: number): void`
Recursion	✅	✅	`Nested { children?: Nested[] }`

Primitives

❌: Interface
✅: Type Alias

string, number and boolean make up the Primitives in Typescript.

Extend / Intersect

✅: Interface
✅: Type Alias

Although intersect and extend are not 100% the same for interface and type alias, I put them together in this example. The differences arise when type keys appear in both types that you want to extend or intersect from.

So if the extended or intersected key is not the same type:

Type Alias lets you do it but changes that type to never
Interface spits an error that the types are not compatible

Mapped object types

❌: Interface
✅: Type Alias

Type the keys in your objects with this.

Here are a few useful applications of this:

[key: string]: only strings as key allowed
[key: number]: only numbers as key allowed
[key in keyof T as `get${Capitalize<string & key>}`]: only allow keys that start with get..., e.g. as seen in a Getter object

Unions

❌: Interface
✅: Type Alias

Typescript’s equivalent to OR: The type is either x or y or z or as many as you want.

Augment existing types

✅: Interface
❌: Type Alias

You can add fields to already existing types. It’s useful when you add a new field (e.g. jQuery library for auto completion) onto an existing type (e.g. window).

Tuples

✅: Interface
✅: Type Alias

If you’ve used hooks in react, then you know the usefulness of tuples.

A single function call can return an array of values and functions, that are destructured and can be used as fully typed variables: const [name, setName] = useState('')

Functions

✅: Interface
✅: Type Alias

Functions can be annotated with Parameter Types and Return Types.

Recursion

✅: Interface
✅: Type Alias

Recursion are simple to use. Make sure you add the optional ? to the recursive property. Otherwise the TS compiler spits out an error upon searching an endless recursion.

More resources

Typescript Playground
Types or Interfaces in react
Interfaces vs Types in TypeScript by Mark
Types vs. interfaces in TypeScript by Leonardo Maldonado
Interface vs Type alias in TypeScript 2.7 by Martin Hochel

If you found this post interesting please leave a ❤️ on this tweet and consider following my 🎢 journey about #webperf, #buildinpublic and #frontend matters on Twitter.

// Detect dark theme var iframe = document.getElementById('tweet-1480863714454687746-808'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1480863714454687746&theme=dark" }

Simon Wicki is a Freelance Developer in Berlin. Worked on Web and Mobile apps at JustWatch. Fluent in Vue, Angular, React and Ionic. Passionate about Frontend, tech, web perf & non-fiction books.

👉 Join me on Twitter to follow my latest updates.

Show Latest Blog Posts in Twitter Header with GitHub Actions

Simon Wicki — Tue, 30 Nov 2021 11:16:31 +0000

I like writing about my dev journey.

Wouldn't it be great if you could show off your latest blog posts in my Twitter header automatically?

This way you could better showcase what you're about. People visiting your Twitter profile will know right away if they should or shouldn't leave a follow.

My Workflow

My GitHub workflow that uses my GitHub action.

This twitter-header-blog-posts-action GitHub Action is responsible for doing the following:

Fetch last 3 blog posts from your blog
Draw fetched blog posts titles onto header
Draw any text onto header
Draw any images onto header
Use Twitter API to upload your dynamic banner

Submission Category:

Maintainer Must-Haves / Wacky Wildcards

Yaml File or Link to Code

In this posts cover image you see my Twitter header that I created with this action. Checkout the following workflow.yml I used to create it:

name: Update Twitter header with latest blog posts
on:
  schedule: # Run workflow automatically
    # This will make it run twice a day (06:00 and 18:00)
    - cron: 0 18 * * *
    # Run workflow manually (without waiting for the cron to be called), through the Github Actions Workflow page directly
  workflow_dispatch:
jobs:
  udpate-twitter-blog-posts:
    name: Update Twitter header with latest blog posts
    runs-on: ubuntu-latest
    steps:
      - uses: zwacky/twitter-header-blog-posts-action@main
        with:
          BLOG_RSS: https://dev.to/feed/zwacky
          DRAW_TEXTS: '[["h1", "Hey, I''m Simon", 125, 100], ["h1", "My latest blog posts", 835, 70], ["h1", "Follow   and say hi!", 545, 390], ["p", "I tweet about webperf, javascript,", 125, 177], ["p", "my learnings and books.", 125, 212]]'
        env:
          TWITTER_API_KEY: ${{ secrets.TWITTER_API_KEY }}
          TWITTER_API_SECRET: ${{ secrets.TWITTER_API_SECRET }}
          TWITTER_ACCESS_TOKEN: ${{ secrets.TWITTER_ACCESS_TOKEN }}
          TWITTER_ACCESS_SECRET: ${{ secrets.TWITTER_ACCESS_SECRET }}

See the how to use section to get a step-by-step guide how to obtain Twitter API credentials and more.

See the input docs to see what customisation is available.

Additional Resources / Info

goodreads-profile-workflow: Another GitHub Action I created—also for dev bloggers!
Check my Twitter @zwacky to see the result!
Check out Erika's action that lets you show your latest followers in your Twitter header—Sweet!

One Font Format to Rule Them All: WOFF2

Simon Wicki — Thu, 11 Nov 2021 07:19:38 +0000

Learn why WOFF2, and WOFF as a fallback, is the only font format you need.

If you’ve been around as a web developer for some time, you’ve seen these font formats in your CSS. Here’s an example for a self-hosted Raleway font:

@font-face {
  font-family: 'Raleway';
  font-style: normal;
  font-weight: 400;
  src: url('../fonts/raleway-v22-latin-regular.eot'); /* IE9 Compat Modes */
  src: local(''),
       url('../fonts/raleway-v22-latin-regular.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
       url('../fonts/raleway-v22-latin-regular.woff2') format('woff2'), /* Super Modern Browsers */
       url('../fonts/raleway-v22-latin-regular.woff') format('woff'), /* Modern Browsers */
       url('../fonts/raleway-v22-latin-regular.ttf') format('truetype'), /* Safari, Android, iOS */
       url('../fonts/raleway-v22-latin-regular.svg#Raleway') format('svg'); /* Legacy iOS */
}

Do we still need to support all 5 (!) of them? Where did they come from? How do they compare to each other?

These questions I’d like to answer in this post.

Timeline

It took time and iterations to have what we’ve ended up with.

With more efficient font formats, thanks to compression, browsers were able to support them.

Have a look at the elaborate Font Format Timeline by Pedro Amado. This shows, that there are in fact many more facets to font formats than we think.

Comparison

I’ll go ahead and use the following criteria for my score to compare font formats:

Browser support as of November 2021
File size (aka format efficiency)

For the file size I used Comic Sans Neue and the browser support I gathered from caniuse.com. Here’s the let’s have a look at the following table ordered historically with these criteria:

Font Format	Release year	Browser support	File size	Score
OTF/TTF	1985	98.6%	57 kb	69/100
SVG	2001	19.4%	113 kb	20/100
EOT	2007	0.87%	27 kb	43/100
WOFF	2009	98.6%	30 kb	88/100
WOFF2	2017	96.8%	23 kb	98/100

Let me explain why WOFF2 scored higher than WOFF in this comparison: It all comes down to the 7 kb in file size. Generally if your site shows the user content more quickly, your conversion will increase—even if the gain is only in the hundred millisecond range.

Your fonts could be:

blocking content from appearing (invisible text)
cause layout shifts
delay further assets from downloading on flaky mobile networks
sending bad signals to Google (LCP & CLS from Core Web Vitals)

How to convert

It's a very good idea to self host your fonts for performance reasons. I described one case in my Time to Say Goodbye to Google Fonts
post.

How to best convert a font type to WOFF2 and WOFF depends where you got your font type from:

Google Fonts: Download the used font types on Google Fonts and use google-webfonts-helper to download the other font formats.
everything else: Use Font Squirrels's Webfont Generator. The 'optimal' setting even only spits out WOFF2 and WOFF files.

Conclusion

WOFF2, and WOFF as fallback, is enough nowadays¹.

¹) if your site doesn't need support for antiquated browsers like IE8.

Simon Wicki is a Freelance Developer in Berlin. Worked on Web and Mobile apps at JustWatch. Fluent in Vue, Angular, React and Ionic. Passionate about Frontend, tech, web perf & non-fiction books.

👉 Join me on Twitter to follow my latest updates.

Keep Your Javascript Bundle Size in Check

Simon Wicki — Wed, 18 Aug 2021 07:34:55 +0000

Are you a developer who is concerned about the size of newly added libraries? Or do you want to find a culprit in a rather big Javascript bundle?

If you’re like me, then you answered yes to both questions.

In this post I’ll cover a few tools that come in handy for a quick analysis of bundle sizes without changing or ejecting your build architecture.

VS Code extension: Import Cost

Understand the cost of an import early.

This extension will display inline in the editor the size of the imported package. It supports tree shaking, so the size should be displayed correctly for a few exported functions.

With this you may spot mistakes like these:

import moment from 'moment'; // 289.7KB
moment.now();

import { now } from 'moment'; // 0.082KB
now();

It’s also available for JetBrains IDE, Atom and Vim.

👉 https://github.com/wix/import-cost

Website: Bundlephobia

his website lets you search for libraries and display their sizes without the need to install. It shows the size of each version and even suggests alternatives to similar libraries that might be lighter—talking about a new framework or library every week.

You could also drop your package.json file and order it by size to see your biggest libraries. Personally I find this quite fun, but usually I use this tool to check bundle sizes of not-yet-installed libraries.

👉 https://bundlephobia.com/

NPM: source-map-explorer

Like the name suggests you need to build source maps. With modern framework CLIs it’s enabled by default in prod builds.

Useful tool for imported package visualisation in relation to their size. By clicking on the packages, you can further imspect their sizes and children.

👉 npx source-map-explorer ./dist *.js
👉 https://github.com/danvk/source-map-explorer

Website: PageSpeed Insight / Lighthouse

If your site is already public you can use Google’s PageSpeed Insight to detect big Javascript bundles.

Bonus: It also includes Javascript files, that are downloaded on runtime from your ad networks, Google Tag Manager and other tools.

👉 https://developers.google.com/speed/pagespeed/insights/

Check out this tweet to see the treemap in action:

Lighthouse

@____lighthouse

The Lighthouse Treemap lets you see what's in the JavaScript you ship and find where you can trim based on module size and execution coverage.

With Lighthouse 8 it's now in PSI, Canary DevTools, and the CLI if it can see your source maps 🌳🗺️

Try it out: googlechrome.github.io/lighthouse/tre…

19:08 PM - 03 Jun 2021

Simon Wicki is a Freelance Developer in Berlin. Worked on Web and Mobile apps at JustWatch. Fluent in Vue, Angular, React and Ionic. Passionate about Frontend, tech, web perf & non-fiction books.

👉 Join me on Twitter to follow my latest updates.

Accurate Daily Measurements of Core Web Vitals with Google Analytics

Simon Wicki — Tue, 10 Aug 2021 09:01:01 +0000

Have you ever optimised your website for the Core Web Vitals (CWV)? Did you want to check your changes the next day—but Google's various tools don't give you current daily CWV metrics due to the rolling 28-day window?

In this post I'll review Google's toolset for measuring CWV and explain how to see if your changes had any effect on CWV day by day with Google Analytics (GA).

Accurate daily CWV measurements: Create your report

There isn't a prebuilt view for daily accurate reports in any analytics service out of the box. That's why we need to create our own report in three steps:

web-vitals: to measure CWV metrics in the frontend
CWV GA tracking snippet: to send these captured metrics over to GA
Web Vitals Report: to create your CWV report by connecting your GA with this external reporting tool

The web-vitals library lets us grab all CWV metrics of each visitor of the site. These metrics are then sent off to Google Analytics. The external Web Vitals Report tool can then extract these tracking events from your GA account and create a daily accurate report.

Don't be fooled: GA can display your CLS, LCP and other CWV metrics when you search for these events. But they're inaccurate in the GA events view. For instance it's possible that multiple CLS events are sent, each with their own delta value that accumulates to the total CLS. You'd need to group by that day and url and user to get an accurate reporting. This grouping isn't supported out of the box.

That's why Google created the external tool Web Vitals Report. You can connect your GA account with it and it will extract the data. If you followed the default naming inside of the CWV GA tracking snippet, everything will work out of the box. You'll be rewarded with shiny graphs and an accurate* report overall.

*) GA imposes a limit in each report which can lead to sampling and an inaccurate report.

The screenshot above is an excerpt of the Web Vitals Report with daily accurate Core Web Vital metrics.

Inaccurate daily CWV measurements: Google's tools

For daily CWV measurements we can't rely on Google's tools because they either aggregate over a long 28-day period or only measure single pages with synthetic, non Real-User Metrics (RUM). So it takes a lot of days to see any change within that period.

Still, Google provides a great—and very easy—overview of your CWV metrics to plan where to optimise next. But you can't check the impact on CWV of your optimisation with these tools, e.g. the next day.

Field data aka real-user experiences:

Google Search Console: measures similar pages
PageSpeed Insights: measures a single page & all pages as a whole
CrUX [Chrome UX Report): measures single pages & all pages as a whole

Lab data aka synthetic user experience:

Lighthouse: measures a single page
Chrome DevTools: measures a single page
Web Vitals Chrome Extension: measures a single page

Rolling 28-day window explained

I dedicate a paragraph to this in particular because the rolling 28-day window appears many times in CWV measurement—especially in how the field data is measured.

Imagine you had 27 days of awful Cumulative Layout Shift (CLS) of 1.0 and on day 28 you magically fix it to 0.

At day 28 your average CLS would be 0.96—which would be rounded up to 1.0 again:

Days      | 1    2    3    4    5    6    7    8    9    10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28
-------------------------------------------------------------------------------------------------------------------------------------------------------
Daily CLS | 1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  0.0 
Average   | 1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  1.0  0.96

In this example above your 1.0 to 0 CLS optimisation would take +23 days until you reach the allowed mobile CLS of 0.1.

See in the following table how slowly the average is decreasing:

Days      | +1   +2   +3   +4   +5   +6   +7   +8   +9   +10  +11  +12  +13  +14  +15  +16  +17  +18  +19  +20  +21  +22  +23  +24  +25  +26  +27  +28
-------------------------------------------------------------------------------------------------------------------------------------------------------
Daily CLS | 0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0  0.0 
Average   | 0.9  0.8  0.8  0.8  0.8  0.8  0.7  0.7  0.6  0.6  0.6  0.5  0.5  0.5  0.4  0.4  0.4  0.3  0.3  0.3  0.2  0.2  0.1  0.1  0.1  0.0  0.0  0.0

More resources

Simon Wicki is a Freelance Developer in Berlin. Worked on Web and Mobile apps at JustWatch. Fluent in Vue, Angular, React and Ionic. Passionate about Frontend, tech, web perf & non-fiction books.

👉 Join me on Twitter to follow my latest updates.

How List Rendering Can Cause Huge Cumulative Layout Shift

Simon Wicki — Wed, 28 Jul 2021 15:55:57 +0000

Do you...

care about Core Web Vitals, especially Cumulative Layout Shift (CLS)
use list rendering with a JS Framework (v-for, *ngFor, ...)

If you answered both with yes, then please read on.

JS frameworks—such as Vue, Angular or React—can cache DOM nodes of list items*. Filtering a list will therefore be faster, because DOM nodes of list items can potentially be reused. This reuse is done by moving the DOM nodes around, instead of re-creating them.

But when a list changes and the nodes of list items merely switch their positions, the reused items are considered as a shift in the DOM (CLS) by Core Web Vitals on slow connection devices.

*) Vue uses :key, React uses key, Angular uses *ngFor with trackBy

Why only on slow connection devices?

CLS takes user interaction into account. When content is changing after a click, it's not counted towards the CLS until a grace period of 500ms. If the delay of content changing takes longer than 500ms, you'll be penalised with the full CLS score.

Fast connection devices will usually finish updating the list before the grace period ends.

Keep an eye out in your Google Search Console for URLs that are frequented by countries that are further away from your servers/CDNs and have a lower average mobile bandwidth.

Solution

Google's calculation of CLS has been changed before, so I would love to see this here too. Until then it's on us to not get penalised.

We'd have to make sure, that the DOM elements get re-created every time a list gets updated or filtered. I wouldn't advise to completely drop the unique key (:key). Rather think of a key for each list item that is tied to the request itself, e.g. :key="item.id + "-" + requestQuery". The filtering itself will have a brief flash due to recreating the DOM node, but considering the Green URLs that Google will give you it's worth it.

With this you can continue with infinite scroll and page navigation without perf loss.

Simon Wicki is a Freelance Developer in Berlin. Worked on Web and Mobile apps at JustWatch. Fluent in Vue, Angular, React and Ionic. Passionate about Frontend, tech, web perf & non-fiction books.

👉 Join me on Twitter to follow my latest updates.

Core Web Vitals explained with GIFs

Simon Wicki — Wed, 21 Jul 2021 05:39:05 +0000

With Google's June 2021 update Core Web Vitals (CWV) will become a factor in SEO ranking.
It measures the quality of a site by these three metrics: LCP, FID and CLS.

If you pass all of them them, Google will reward you with more visibility.

You can check how well you do on these metrics via several ways:

Pagespeed Insights
Search Console
WebDev Measure
Chrome DevTools & Lighthouse
Web Vitals Chrome Extension
Custom event tracking with Google Analytics

Largest Contentful Paint (LCP)

LCP marks the point in the page load timeline when the page's main content has likely loaded.

—web.dev

The faster you make the biggest content on the above-the-fold appear, the better your metric will be.

If you can preload the biggest image already, e.g. with <link rel="preload" href="..."> or make the content appear without rendering it with your Javascript Framework, you'll win big.

Causes of LCP:

Slow server response times
Render-blocking Javascript and CSS
Slow resource load times
Client-side rendering

First Input Delay (FID)

FID measures the time from when a user first interacts with a page to the time when the browser is actually able to begin processing event handlers in response to that interaction.

—web.dev

Javascript is synchronous and single-threaded. If a user interaction happens while the thread is busy, the user has to wait. If you have too many libraries that load at runtime, worse even if you don't need them right away, this can increase the FID.

It's similar to TTI (Time to Interactive) that you might have heard of already. However FID will only start to be measured from the user interaction. Whereas TTI will be measured from the very start of loading the site.

Causes of FID:

too much javascript code to execute right away, especially 3rd party
ad networks can push lots of unneeded Javascript
not using code-splitting (e.g. with webpack, Rollup, Parcel)

Cumulative Layout Shift (CLS)

CLS is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifespan of a page.

—web.dev

Layout shifts only happen when an element higher up is making other elements move. If the element is changing and there is nothing after it, it doesn't count as a layout shift—as well as DOM changes that were caused by a user interaction with a grace period (500ms).

Note: Mobile viewports and 3G devices will cause much more CLS. Make sure to throttle your connection while optimising your page for these metrics.

Causes of CLS:

images without size attributes
requests finish later that will inject content above existing content
lazy loaded components

Simon Wicki is a Freelance Developer in Berlin. Worked on Web and Mobile apps at JustWatch. Fluent in Vue, Angular, React and Ionic. Passionate about Frontend, tech, web perf & non-fiction books.

👉 Join me on Twitter to follow my latest updates.

Pimp Your GitHub Profile with Books You Read

Simon Wicki — Sun, 11 Apr 2021 10:18:57 +0000

In this post I'd like to show you how to use GitHub Actions to automatically sync your Goodreads books you read in your GitHub profile README.

I created goodreads-profile-workflow for devs that love to read and like to share what they read. You can customise the input parameters to your liking: list the books you're currently reading, last 5 books you read and even add your personal ratings, too.

zwacky / goodreads-profile-workflow

Show what you're currently reading and recently read on your GitHub profile readme.

Leave a star on the repo if you think it's cool!

GitHub Actions and Profile READMEs

When you head over to your GitHub profile page, https://github.com/zwacky in my case, you'll see that you can do more than just pin repositories. If you're missing yours, check out the official docs on GitHub to get one, too.

Keeping your profile README fresh with up-to-date data is a great way to show your visitors what you're up to or what you've been working on. Either you do it manually or you automate it with the help of GitHub Actions. They can run workflows periodically and update your README for you.

There are tons of great ones out there. Have a look at the great list awesome-github-profile-readme repo for inspiration. They include GitHub Actions that can:

update your latest blog entries
update your GitHub activity
or even update your sleep data from your sleep tracker

How To Use

I'll quickly explain here how to use goodreads-profile-workflow and what the GitHub Actions do. For a full step-by-step guide read the how to use section of the project.

#1 Add placeholders to your README

Your README.md will be updated and eventually updated every hour by the GitHub Action. So it needs to know where the list begins, and where it ends. The content inbetween will then be replaced with the latest content. As an example it could look like this:

# Hey there 👋
I'm Simon and live in Berlin as a Freelance Frontend developer.

# Last 5 Books I've Read 🤓
<!-- GOODREADS-LIST:START -->
<!-- GOODREADS-LIST:END -->

You can customize the GOODREADS-LIST tags, so you can have multiple workflows updating different sections in your README. This is also what I'm using to get to the screenshot at the top of this post.

#2 Create a workflow file

Create a file in your own GitHub profile repo so it's located at: {REPO}/.github/workflows/goodreads-books-workflow.yml.

GitHub Actions look for *.yml files in the /.github/workflows directory. These files are called workflows.

In this workflow file you can paste the following:

name: Latest book list from goodreads
on:
  schedule: # Run workflow automatically
    # This will make it run every hour
    - cron: "0 * * * *"
    # Run workflow manually (without waiting for the cron to be called), through the Github Actions Workflow page directly
  workflow_dispatch:
jobs:
  update-readme-with-goodreads-books:
    name: Update this repo's README with what you're currently reading
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: zwacky/goodreads-profile-workflow@main
        with:
          # Replace this with your goodreads user id (go to "My Books" on goodreads to see it in the URL)
          goodreads_user_id: "92930971"
          shelf: "currently-reading"

The last lines are input parameters. Make sure you change them with your Goodreads ID.

Have a look at all the input parameters and template variables that goodreads-profile-workflow support.

#3 Commit and trigger the workflow

If you head over to the Actions tab in the repo. You should see your "Latest book list from goodreads" workflow. This is also where you can see if the job ran successfully or if there is an issue or typo.

Alternatively you could also wait until the scheduler picks up on the "0 * * * *" setting (every hour) in the yml workflow.

#4 Done 🎉

Hope you find this workflow useful! Please reach out via GitHub issues or Twitter. Excited to hear from all the different reading lists and how your profile looks. Please consider leaving a GitHub star.

Simon Wicki is a Freelance Developer in Berlin. Worked on Web and Mobile apps at JustWatch. Fluent in Vue, Angular, React and Ionic. Passionate about Frontend, tech, web perf & non-fiction books.

👉 Join me on Twitter to follow my latest updates.