Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

website: hero poster is 1920x1080 for a 1359x764 render — 36 KiB of image-delivery waste

未关闭 适合新手
  • 哪里不对？
#876 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
84/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
typescript
领域
frontend, performance

调研方向

阅读 website/site/src 的 Hero.astro 和 Base.astro，以及 FilmScreen.astro，追踪海报和 Open Graph 图像的使用位置。调整海报尺寸以用于 hero，同时保留 1920 × 1080 的资源用于 og:image；然后检查海报大小、在桌面和手机宽度下的视觉呈现、CLS，以及 Lighthouse 的图像交付审核。

由索引模型根据 Issue 内容生成。

描述

Website

Where this comes from

A Lighthouse 13.4.1 report for https://ema.tnsor.network/ (mobile defaults, fetched 2026-10-17 12:29:42Z). Performance 95, CLS 0, LCP 0.4 s. Every image-geometry audit passes — unsized-images and image-aspect-ratio both score 1 with zero items.

The one image finding is delivery, not geometry:

audit: image-delivery-insight
url:            https://ema.tnsor.network/media/hero-poster.webp
totalBytes:     73916
wastedBytes:    36890
reason:         This image file is larger than it needs to be (1920x1080)
                for its displayed dimensions (1359x764).
                Use responsive images to reduce the image download size.

The file and its two consumers

website/site/public/media/hero-poster.webp is 1920 × 1080, 73,916 bytes — the report's totalBytes is that file exactly.

  1. The hero film's <video poster> — Hero.astro:25 passes it to FilmScreen.astro:16 (<video … poster={poster}>). This is the element the audit measured, and the rendered box is 1359 × 764 CSS px on a desktop viewport.
  2. The Open Graph image — Base.astro:17 builds og:image from the same path. Social cards want 1200 × 630 or larger, so this consumer must not shrink.

Proposed change

Split the two consumers and size each for its use:

  • Keep a 1920 × 1080 og-hero.webp for Base.astro's og:image.
  • Add a page-sized poster, around 1440 × 810 (≈ 20–25 KB at the same quality), and point Hero.astro at it.
  • If the poster looks soft on a 2× display, set it from a tiny inline script using devicePixelRatio — the hero already ships one for data-autoplay, so choosing between hero-poster-1440.webp and the 1920 file costs nothing extra. Measure before adding that branch: at 1359 CSS px wide a 1440 file is ~1.06× and may be acceptable.

Do not solve this with a blanket quality drop — the audit's waste is resolution, not encoding.

Acceptance criteria

  • image-delivery-insight no longer reports hero-poster.webp, and the poster request is ≤ 45 KB.
  • CLS stays 0, and the poster renders visually identical at desktop (1359 × 764) and phone widths.
  • og:image still resolves to a 1920 × 1080 asset, and the social-card preview is unchanged.
  • Record the before/after bytes and the Lighthouse audit result in the PR.

Measured candidates

Encoded from the current file with ffmpeg -vf scale=W:-2 -c:v libwebp -quality 82 (matching the source's apparent quality; check visually before committing):

width bytes saving vs 73,916
1920 (current) 73,916 —
1440 40,908 33,008
1280 35,828 38,088

The audit estimated 36,890 B of waste, so either candidate removes essentially all of it. 1440 is the better default: it is 1.06× the desktop render box, so a single file needs no devicePixelRatio branch.

主要语言
TypeScript
星标
829
派生
234
平均合并
22 小时 43 分钟
30 天内合并 PR
52

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

cameri/nostream 的其他 Issue

查看 cameri/nostream 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。