Image fetch and display optimization on the landing page (LCP 404 ms → poster priority, sizing, caching)
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 新手友好度
- 35/100
- Issue 類型
- 重構
- 描述清晰度
- 基本清楚
- 活躍度
- 活躍
- 技術堆疊
- html, javascript
- 領域
- frontend, performance
研究方向
Start in website/site/src/components/FilmScreen.astro where the hero video poster and attributes are set, then check Base.astro for a possible preload and the inline module in the built index.html. Caching needs a new website/site/public/_headers file and wrangler.jsonc, and the poster resizing belongs in the pnpm run media pipeline under website/hero-animation/. Done means the acceptance checklist holds: High poster priority in DevTools, a smaller poster on a 1318×741 viewport, Cache-Control on /media/*, and LCP under 300 ms.
由索引模型根據 Issue 內容生成。
描述
Context
LCP analysis of ema.tnsor.network (measured 2026-10-16): LCP is the hero <video>'s poster frame (/media/hero-poster.webp), landing at 404 ms with a 312 ms render delay after the image finishes downloading (~92 ms). Full diagnostics:
| Metric / Attribute | Value | Finding |
|---|---|---|
| LCP Timing | 404 ms | Total render delay is 312 ms. |
| Image Priority | Medium | Failed fetchpriority=high check. |
| Resolution | 1920×1080 | Oversized for the 1318×741 display area. |
| Potential savings | 39.1 KB | Oversized resolution wastes bytes. |
| Cache policy | max-age=0 |
Forces re-validation on every request. |
Render delay breaks down to a ~205 ms layout task plus script execution (line 19, col 5131 — inline module in the built index.html) competing with the poster's first paint.
Current markup (FilmScreen.astro)
<video muted loop playsinline preload="auto" poster={poster} data-autoplay data-low-src={lowSrc} aria-label={title}>
No fetchpriority, no responsive source, and Cloudflare Workers static assets currently emit no cache headers (no _headers file; wrangler.jsonc assets.directory only).
Recommendations
- Elevate resource priority —
fetchpriority="high"on the video (applies to the poster fetch). Optionally add a<link rel="preload" as="image">for the poster inBase.astrowhen the hero is above the fold. - Responsive sizing — the poster is 1920×1080 but the display area measured 1318×741. Serve a smaller default with
srcset/<picture>(e.g. 960/1318/1920 widths), or accept the ~39 KB penalty on desktop. Note the poster doubles as theog:image, so generate both variants from the same source inpnpm run media. - Minimize main-thread work — the ~205 ms layout task + inline script at first paint delay the render even after the bytes arrive. Audit the initial inline module (spark canvas init, IntersectionObserver setup, reveal class) for anything that can yield or move behind
requestIdleCallback. - Improve caching — static assets are content-hashed only in name (they aren't —
hero-poster.webphas no hash). Add awebsite/site/public/_headersfile (Cloudflare Pages syntax works with Workers static assets) mapping/media/*to a longmax-age+immutable, or hash filenames. Careful:hero.mp4changes with each hero re-render, so prefer_headerswith a boundedmax-age(e.g. 1 week) overimmutableunless filenames get hashed.
<!-- Example: adding fetchpriority to a video poster -->
<video poster="/media/hero-poster.webp" fetchpriority="high">
<!-- ... -->
</video>
Note: findings above were identified on a live page in DevTools. Adapt to the stack (Astro components in website/site/src/components/FilmScreen.astro, build pipeline in website/hero-animation/) rather than applying literal CSS overrides.
Acceptance
- Poster fetch reports
Highpriority in DevTools network - Poster transfer ≤ 1318×741-equivalent size on that viewport (or documented decision to keep 1080p for large screens)
-
_headersserving/media/*withCache-Control: public, max-age≥604800(verified withcurl -sI https://ema.tnsor.network/media/hero-poster.webp | grep -i cache) - LCP re-measured with the same methodology; target < 300 ms
- 主要語言
- TypeScript
- 星號
- 829
- 分支
- 234
- 平均合併
- 18 小時 18 分鐘
- 30 天內合併 PR
- 69
環境準備
- 提供 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
cameri/nostream 的其他 Issue
-
rust.sh shares one CARGO_TARGET_DIR across worktrees, so a scratch-copy build poisons the next run未關閉
難度 2/5 1-3 小時 新手友好度 68/100
維護者通常 1 天內回覆
-
Website
難度 2/5 1-3 小時 新手友好度 84/100
維護者通常 1 天內回覆
-
feat(payments): subscription lifecycle, renewal invoices and plan-based write access可能已有人在做 @Priyanshubhartistm 今天認領。 未關閉enhancement
cameri/nostream#908 · 已指派 1 人 ·
維護者通常 1 天內回覆
-
難度 4/5 3-5 天 新手友好度 72/100
維護者通常 1 天內回覆
-
難度 3/5 1-2 天 新手友好度 72/100
維護者通常 1 天內回覆
相似的 Issue
-
docs(api): openapi.yaml still documents gif-tools optimize colors as 2-256 instead of 2, 4, 16, 256未關閉area: backend documentation priority: low
難度 2/5 1-3 小時 新手友好度 84/100
snapotter-hq/SnapOtter#2919 ·
維護者通常 1 天內回覆
-
accepted :+1: bug db/redis
難度 2/5 1-3 小時 新手友好度 76/100
beekeeper-studio/beekeeper-studio#4882 · 1 則留言 ·
維護者通常 1 天內回覆
-
ready-for-triage
難度 2/5 1-3 小時 新手友好度 72/100
konflux-ci/konflux-ui#1630 · 1 則留言 ·
維護者通常 2 天內回覆
-
難度 2/5 1-3 小時 新手友好度 67/100
ahmedkhaleel2004/gitdiagram#233 ·
-
難度 2/5 1-3 小時 新手友好度 72/100
simkimsia/netlify-axi#19 ·
維護者通常 1 天內回覆