WICG / WICG/container-timing

How should we handle skeleton screens?

Open
#24 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Bikeshed
Stars
72
Forks
10
Avg merge
9d 15h
Merged PRs (30d)
3

Description

Describe the bug

A skeleton screen is used as a placeholder while users wait for a page to load. This progress indicator is used for full page loads and reduces the perception of a long loading time by providing clues for how the page will ultimately look.
https://www.nngroup.com/articles/skeleton-screens/

These are more useful to the user because they show a "shadow" of the website layout before content has come in. However, because the grey areas are usually in the same position of actual content we may not get a PerformanceContainerTiming event when content does eventually come through.

There may not be anything we can do about this and that's how it is, but this is a good time to discuss it whilst changes can be made.

LCP already ignores low-entroy images so we should be leveraging the same heuristics that LCP use. If that is the case we are fine.

We would need the same spec text written here for LCP:

Image

To Reproduce

  • Clone the repo
  • npm i; npm run start
  • Navigate to the skeleton-layout example
  • Open devtools and observe the entry being recorded

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by running npm i; npm run start, opening the skeleton-layout example, and observing the recorded entry in devtools. Read the linked LCP heuristic and specification text, then determine whether skeleton placeholders prevent a PerformanceContainerTiming event; done means establishing whether the existing heuristic is sufficient or documenting the required spec change.

Written by the indexing model from the issue text.

Assessment

Domain
performance, web-dev
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.