From Chris, in chat:
and then lets make sure we get the marketing page improved some more home-lang.org that it has all the proper og images, meta info, etc. for all pages make sure benchmarks are accurate please as well make sure analyticshq is properly tracking that site too make sure the docs are accurate too improve the docs too (remove stuff like these paths
/Users/chrisbreuer/Code/bun/...etc)
Five separate asks that happen to share a surface. Splitting them out, because the benchmark one is not like the others.
Marketing page and metadata
- OG images for every page, not just the home page. A link to any docs page currently shares with whatever the default is
- Per-page title and description, distinct rather than templated off the site name
- Twitter/X card tags, since the accounts being set up now will be posting these links
- Canonical URLs
- Check what a real share looks like, in a validator rather than by reading the markup
Docs
- Accuracy pass against current behaviour
- Remove local absolute paths such as
/Users/chrisbreuer/Code/bun/.... These leak a contributor's directory layout into published docs and are never reproducible for a reader - A guard so they cannot come back. A test that greps the docs corpus for
/Users/,/home/, and absolute paths under a home directory is a few lines and holds forever. Placeholders like/Users/username/are fine and should stay allowed, which is what the Stacks docs use
Analytics
- Confirm AnalyticsHQ is actually receiving pageviews from home-lang.org, by looking at delivered events and not just at the presence of the script tag
- Decide whether the docs pages are tracked as well as the marketing pages
Benchmarks: the one with a methodology problem
"Make sure benchmarks are accurate" is the hardest item here, and accuracy is not a proofreading pass. From the measurement work on stacksjs/stacks#2779:
Absolute numbers are not comparable across runs on hosted machines. The same stock workload measured 14.90 us/req on one runner and 28.57 us/req on another, for identical source. One run was a 4-core Xeon 8573C, another an EPYC 7763. Any published figure that compares a number from one run against a number from another is measuring the runner, not the thing.
What that means for a published benchmark:
- Every comparison is within a single run, on one machine, against the alternatives measured in that same run
- State the repeat count, and publish a median rather than a best-of
- State the machine, the core count, and the toolchain versions next to the numbers
- Keep the raw output of the measuring tool as an artifact, so a number can be traced back
- A ratio against a baseline measured in the same run survives a hardware change; a bare microsecond figure does not
- Re-measure before publishing. Numbers taken from an older run on different hardware cannot be refreshed by editing the page
If any current figure on the site cannot be traced to a run that measured its comparison points together, it should come down rather than be adjusted.
Acceptance
- Sharing any page produces a correct, page-specific preview
- No published doc contains a path from a contributor's machine, and a test fails if one returns
- AnalyticsHQ shows delivered events from the site
- Every published benchmark figure names its machine and repeat count, and its comparisons come from one run
Part of stacksjs/stacks#2874, which indexes the five workstreams from the same conversation.