content-visiblity: auto; vs. jumpy scrollbars, a solution

As warned in content-visibility: the new CSS property that boosts your rendering performance you need to be careful with applying content-visibility: auto; on each and every element as the scrollbar might get jumpy.

This is because elements will be rendered as they scroll into the viewport and will be hidden as they scroll out of the viewport, thereby affecting the height of the rendered page, and thus also affecting the scrollbar.

ℹ️ Apart from a jumpy scrollbar it can also negatively affect accessibility when you include headings and landmark elements inside of regions styled with content-visibility: auto;. See Content-visibility and Accessible Semantics for details.

Now, thanks to infinite scroll we are β€” or at least I am β€” kind of used to the thumb part of the scrollbar shrinking and jumping back up a bit on the scrollbar track as you scroll down. What we’re not used to is the thumb part jump forwards on the scroll track as you scroll down. This is because elements that slide out of the viewport will no long be rendered β€” as that’s what content-visibility: auto; does β€” and the scrollbar is (by default) only calculated against the rendered elements.

Elements can become non-rendered elements as they scroll out of the viewport,
thanks to content-visibility: auto; doing its thing.

To cater for this jumpy behavior you should use contain-intrinsic-size so space for an element is reserved when it’s not being rendered. However, it is not always possible to know a box its dimensions in advance. Looking for a way to automatically reserve space for previously rendered elements, Alex Russel created a little script for it.

One challenge with naive application of content-visibility, though, is the way that it removes elements from the rendered tree once they leave the viewport — particularly as you scroll downward. If the scroll position depends on elements above the currently viewable content “accordion scrollbars” can dance gleefully as content-visibility: auto does its thing.

In a first version of the script he applied content-visibility: visible on each element from the moment it had appeared on screen. To detect this an IntersectionObserver is used. While this does prevent the scrollbar thumb from jumping forwards as you scroll down, it will make the page slow again as that content remains rendered (even though it’s off-screen).

A second version of the script takes a different approach and calculates the contain-intrinsic-size to apply based on the element’s dimensions. That way elements that passed by once now have a correct contain-intrinsic-size set, and can safely be hidden again as content-visibility: auto does its job.

let spaced = new WeakMap();
let reserveSpace = (el, rect) => {
    let old = spaced.get(el);
    // Set intrinsic size to prevent jumping.
    if (!old || rectNotEQ(old, rect)) {
        spaced.set(el, rect);
        `${rect.width}px ${rect.height}px`

Additionally he also added a ResizeObserver to cater for resize events.

Resize-Resilient `content-visiblity` Fixes →

πŸ€” Clever script indeed, yet I cannot help but think: this should be possible without the needs for this extra script. What if a value like contain-intrinsic-size: auto; would be allowed, and do exactly as the script Alex built does?

UPDATE: I’ve created an issue on GitHub that proposes contain-intrinsic-size: auto;. Let’s see where this goes …

How to useRef to Fix React Performance Issues

Sidney Alcantara who works on Firetable, a product which features a data grid and an adjacent side drawer. When clicking a cell in the table, the side drawer opens with info about the current cell. Initially they lifted up the state, but that caused performance issues:

The problem was whenever the user selected a cell or opened the side drawer, the update to this global context would cause the entire app to re-render. This included the main table component, which could have dozens of cells displayed at a time, each with its own editor component. This would result in a render time of around 650 ms(!), long enough to see a visible delay in the side drawer’s open animation.

After exploring to split the context, or resort to useMemo/React.memo they settled on useRef to solve this.

Good use-case and detailed write-up!

How to useRef to Fix React Performance Issues →

Beyond Fast: Features to Improve the Performance of your Web Pages

Few tips by Jake Archibald β€” as presented at #ChromeDevSummit β€” on how you can use some of the new and upcoming web features to improve the performance of your page.

Covered are the aforementioned content-visibility, Font metric override descriptors, the Back/Forward Cache, Portals, and Preloading

httpstat – curl statistics made simple

httpstat visualizes curl(1) statistics in a way of beauty and clarity.

It is a single file🌟 Python script that has no dependencyπŸ‘ and is compatible with Python 3🍻.

Installation through PiP or HomeBrew:

pip install httpstat
brew install httpstat

Once installed through one of those, you can directly call httpstat:


httpstat – curl statistics made simple →

content-visibility: the new CSS property that boosts your rendering performance

Coming to Chromium 85 is content-visibility (part of Display Locking):

content-visibility enables the user agent to skip an element’s rendering work, including layout and painting, until it is needed. Because rendering is skipped, if a large portion of your content is off-screen, leveraging the content-visibility property makes the initial user load much faster. It also allows for faster interactions with the on-screen content. Pretty neat.

You see that correct in the image above: rendering went from 232ms down to 30ms … that’s a 7x improvement!

Now don’t go plastering this all over your site, but use it carefully. As Una noted:

Combined with contain-intrinsic-size it’d look like this:

.story {
  content-visibility: auto;
  contain-intrinsic-size: 1000px;

content-visibility: the new CSS property that boosts your rendering performance →

The Ultimate Guide to React Native Optimization

The folks over at Callstack have published a series on React Native Optimization:

In this and the following articles, we will show you how to optimize the performance and stability of your apps. Thanks to the practices described in the guide, you will improve the user experience and speed up the time-to-market of your apps.

The whole guide is divided into 18 articles, which will be published regularly. Over time, all these articles will be collected in one place and made available as one large ebook for download.

By now 5 parts have been published online so far:

  1. Reducing the device’s battery usage with UI re-renders
  2. The best practices around using dedicated higher-ordered React Native components
  3. Picking external libraries
  4. Choosing Libraries optimized for mobile
  5. Find the balance between native and JavaScript

Well worth a read!

Need to Connect to a Local MySQL Server? Use Unix Domain Socket!

The folks at Percona have benchmarked TCP/IP vs. Unix Connections to a local MySQL server.

When connecting to a local MySQL instance, you have two commonly used methods: use TCP/IP protocol to connect to local address – localhost or – or use Unix Domain Socket.

If you have a choice (if your application supports both methods), use Unix Domain Socket as this is both more secure and more efficient.

Not that the exact numbers really matter, but the message should be clear: Use a Unix Domain Socket to connect, if you have the chance.

Need to Connect to a Local MySQL Server? Use Unix Domain Socket! →

React Performance Optimization with React.memo()

I know I’ve posted a similar article before but this is a pitfall I commonly see and therefore it can’t be repeated enough.

React internally already optimizes the performance quite a bit without having to explicitly optimize for performance. React.memo can help you to optimize the number of renders of your React components even further.

In this article I will explain to you how you can optimize React performance by using React.memo, some common pitfalls you could encounter and why you shouldn’t always use React.memo.

React Performance Optimization with React.memo()