Spinners versus skeletons in the battle of hasting

Martin Nuc

Martin Nuc

Software engineer at Productboard

martinnuc

MartinNuc

@martin_nuc

Agenda

  1. Performance issues in PB
  2. Theory of loading states
  3. Two issues we had
  4. How Design system helped

"Productboard is slow to load"

Huge JS bundle

10.8 MB

Slice up the Productboard

✂️

split app into chunks by routes

const loadMyComponent = () =>
  import(
    /* webpackChunkName: "awesome-chunk" */
    'src/js/MyComponent'
  );

const LazyMyComponent = React.lazy(loadMyComponent);

<Suspense fallback={<LoadingSpinner />}>
  <LazyMyComponent />
</Suspense>

https://reactjs.org/docs/code-splitting.html​

Chunks (~60)

10.8 MB down to 3.8 MB

Delay when navigating

😠

How to identify loading state in the app?

UX Theory

🌀 Loading spinner

🥁 Progress bar

☠️ Loading skeleton

Don't do's

❌ Multiple spinners

❌ No response on click

❌ Short spinner

❌ Long spinner

Chunks (~60)

Three cases

🏎 really fast parts

🚙 reasonably fast

🐢 slow large pages

300ms

1500ms

Spinner

Skeleton

No indicator

Two issues

  1. the fallback is always rendered
  2. identify slow pages

1st issue

the fallback is always rendered

🎨

=

spinner shows even when not necessary

🤬 Suspense fallback is always rendered

Suspense

Suspense

  • prevents rendering it's children component until its data are ready
  • experimental
  • API for React.lazy + Suspense won't change
const Suspense = ({children, fallback}) => {
  try {
    return children;
  } catch {
    return fallback;
  }
}

🤔 When is children ready?

const Suspense = ({children, fallback}) => {
  try {
    return children;
  } catch(thrownPromise) {
    thrownPromise.then(() => rerender());
    return fallback;
  }
}

Fallback always rendered

const Suspense = ({children, fallback}) => {
  try {
    return children;
  } catch(thrownPromise) {
    thrownPromise.then(() => rerender());
    return fallback;
  }
}

First render always throws

💡 postpone rendering of fallback

"DelayedComponent"

Usage

<Suspense fallback={
  <DelayedComponent delay={300}>
    <LoadingSpinner />
  </DelayedComponent>
}>
  <ComponentFetchingData />
</Suspense>
export const DelayedComponent = ({children, delay}) => {
  const [shouldDisplay, setShouldDisplay] = useState(false);
    
  useEffect(() => {
    const timeoutReference = setTimeout(() => {
      setShouldDisplay(true);
    }, delay);

    return () => {
      clearTimeout(timeoutReference);
    };
  }, [delay]);
  
  if (shouldDisplay) {
    return children;
  } else {
    return null;
  }
}

✅ fallback renders only when needed

2nd issue

Identify slow pages

☠️

🙁 we had no visibility into components rendering

Identify slow pages

💡 track DelayedComponent lifecycle

DelayedComponent

nothing

Spinner

Suspended content

loading done

300ms

⏱ rendered

⏱ fallback displayed

⏱ component unmounted

✅ identified slow pages (>1500ms)

🔧 crafted skeletons for them

🧩 Design system

  • helped tremendously!
  • speedup crafting skeletons

👍

🥡 Take aways

  • measure your app performance
  • pick the best solution based on ⤴️
  • deliver the best UX to the user

📎 https://bit.ly/3n3aE9M

Q&A

Is it perfect?

Spinner

300ms

350ms

❌ Fast spinner here!

Finished loading

It's a trade of

Spinner

300ms

350ms

Finished loading

600ms

250ms

no fast spinner or faster render?

Spinners vs Skeletons

By Martin Nuc

Made with Slides.com

Spinners vs Skeletons

  • 204

More from Martin Nuc