Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Show error bars on timing metrics

Open
  • Is something wrong?
#633 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
38/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
data-visualization, frontend

Research direction

Start by finding where the timing JSON is loaded and where the charts and tables render these metrics, then check the install and FCP entries for the standardDeviation(Ms) field and raw samples. Error bars on charts and ± in tables should first cover install and paint metrics, which already have spread data. Recording spread for SSR throughput and load is a separate benchmark change, and the issue does not say how error bars should look, so confirm that with maintainers before you start.

Written by the indexing model from the issue text.

Description

The timing metrics that are measured by framework-tracker itself (install, cold/warm build, dev server start, FP/FCP, interaction breakdown, SSR throughput/load latency) are noisy by nature. The site currently shows one number per framework, so small differences look meaningful even when they're within noise. Showing a single value without its spread isn't really as honest as it should.

A couple of examples from the current Next.js data:

  • install time: 5744 ms avg, std dev 1688 ms (samples: 2729 to 6631)
  • client-side FCP: 405 ms avg, std dev 141 ms

Most of this data is already collected: standardDeviation(Ms) and raw samples are in the JSON for install, builds, dev server start, and the CSR/SSR paint and interaction tests. It's just not displayed anywhere.

Proposal

  • Add error bars to charts (and ± in tables) for every timing metric framework-tracker measures itself
  • Start recording spread for the ones that don't have it yet (SSR throughput, SSR load)
  • 3rd-party data (HTTP Archive CWV): I don't know what spread info the source provides, but if it's available, show it there too
  • Exact counts and sizes (dependency counts, node_modules size, …) don't need any of this

Related: #407

Dominant language
TypeScript
Stars
42
Forks
16
Avg merge
14h 3m
Merged PRs (30d)
149

Getting set up

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.

More from e18e/framework-tracker

All issues in e18e/framework-tracker

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.