AI 摘要：本文章批判了将 SPA（单页应用，Single Page Application）作为优先方案的潮流，指出随着现代 CSS 和浏览器（如 View Transitions API、Speculation Rules 等）的进步，实现流畅、原生的页面交互已不再需要复杂的 JS 框架和大量前端代码。作者呼吁开发者回归标准的 HTML + CSS + 浏览器原生能力，构建更快速、可维护、SEO 友好的网站，并强调 SPA 带来的复杂性、性能损耗、可访问性问题，以及与浏览器发展脱节的弊端。

1. “类应用”迷思与 SPA 的错误假设
• 许多项目由于“要像 app 一样流畅”的陈旧要求选择了 SPA 架构，而忽略了是否真的需要。
• 选择 SPA 并非出于真正的技术需求，而是为交互流畅度妥协了架构简洁性。
• 现在的假设已过时，SPA 不再是唯一可实现流畅体验的方法。

2. SPA 的“伪流畅”与性能危害
• SPA 的“无刷新感”常常是假象，实际表现为加载动画、滚动错乱、路由行为不一致等问题。
• 大量 JavaScript 的引入导致性能下降，SEO 变得复杂，体验反而变差。
• 现代 SPA 阈值带来的技术负担，不成比例的为“流畅度”买单。

3. 现代 Web 平台演进（CSS 与浏览器原生特性）
• 浏览器原生已支持声明式页面过渡（View Transitions API），无需 JS 也能实现淡入淡出动画等高级体验。
• 结合 Speculation Rules（预测性预加载），可实现点击即开的导航体验，无需 JS 路由。
• 原生 MPA（多页面应用，Multi-page Application）方案能够通过 CSS 动画实现元素过渡、状态保存、URL 正确性等。
• 示例代码简明说明如何用 CSS 实现页面转场与共享元素动画。

4. 浏览器赋能与简单架构的优势
• 现代浏览器提供诸如 Back/Forward Cache（前进后退缓存）等特性，只要结构易读、无 JS 路由劫持即可天然获得极佳体验。
• 浏览器愿意协助性能优化，但前提是开发者不要人为增加复杂度。

5. 性能现实对比：SPA vs 现代 MPA
• 真实 SPA（如 Next.js 等）JS 体积大，加载慢，SEO 和导航表现不稳定。
• MPA + View Transitions + Speculation Rules 几乎无需 JS，加载极快，自然支持 SEO 和历史管理。
• 原生方法不仅替代 SPA 行为，而且性能和可维护性更佳。

6. 反思：“网站不是 APP”
• 普通网站无需 SPA 的状态管理、复杂路由、大量组件或 hydration。
• 使用过度的 JS 反而增加了网站开发、运维成本和用户负担。
• 理性选择开发手段，应“用网站的方式造网站”，拥抱标准技术栈。

7. 展望与建议：用现代 web 技术构建网站
• 原生 declarative transition（声明式过渡）、预渲染、降级兼容性、易维护架构等已足以满足绝大多数场景。
• SPA 是旧时代局限下的策略，如今实属多余。
• 建议开发者用现代服务端渲染和单纯 HTML + CSS 构建主站，只在必要时合理由加 JS 增强。

Jono Alderson

It's time for modern CSS to kill the SPA

Native CSS transitions have quietly killed the strongest argument for client-side routing. Yet people keep building terrible apps instead of performant websites.

AI 摘要：Google Chrome 的 Performance Extensibility API （性能扩展 API）允许开发者将自定义的性能标记（performance.mark）和测量（performance.measure）集成进 Chrome DevTools 的性能面板，使自有应用、团队代码与第三方包可实现更细粒度、结构化和可视化的性能剖析。文中不仅介绍 API 的最小可用实践和高级特性（如自定义 track、颜色、分组与元数据），还探讨了如何借助这些新能力更好地组织跨团队、跨模块或第三方依赖的性能数据，以提升前端调优的效率和可读性。

1. 背景与意义
• Google Chrome 推出的 Performance Extensibility API 能让开发者自定义性能分析数据，在 DevTools 性能面板中更清晰展现。
• 适用于关注特定应用片段性能、跨团队协作及 API/第三方包开发者等多类场景。

2. 现有能力回顾（性能.mark 与 .measure）
• 介绍 performance.mark() 与 performance.measure() 的基础用法，展示如何标记重要事件并测量阶段耗时。
• DevTools 能自动捕获这些标记，方便用时长和起止点可视化查看。

3. Extensibility API 的最小实现
• 启用 DevTools 新特性（Show custom tracks）。
• 使用 mark 时 dataType 必填，measure 时 track 必填，其他均为可选。
• mark 实现更明显的“标志”，但缺乏精确时间信息，偏向定位关注点而非精确计时。
• measure 则可直接建立自定义轨道，并展现分时区间。

4. 高级用法与增强能力
• 支持自定义颜色（限定调色板）、显示 toolTipText 与挂载元数据（properties）。
• measure 可作详细事件描述和元数据列举（例如资源加载性能拆解）。
• 所有扩展项 (color、tooltipText、properties) 均适用于 mark 与 measure，但 measure 的实用性更强。

5. track 与 trackGroup 的组织能力
• 支持创建自定义 track（如 CSS、JS、API）以区分不同事件流。
• 支持 trackGroup，将多个 track 归为一个分组（例如 First Party < CSS、JS>），适合团队协作及区分自有与第三方数据流。
• 实现方式简便，极大提升了跨团队、模块性能整理与溯源的效率。

6. 实践建议与最佳实践
• 推荐从最小实现用法入手，不建议对 mark 过度扩展。
• 优先使用 measure 进行自定义 track/trackGroup 的组织管理。
• 针对第三方库或框架，鼓励将自有 Instrumentation 移入单独 trackGroup，以提升定位和用例分析效率。

7. 附录：实用代码示例
• 提供结合 Resource Timing API 的实践 demo，展示如何自动获取和展示资源性能细节。

Csswizardry

Making Sense of the Performance Extensibility API – CSS Wizardry

Making sense—and use!—of the new Performance Extensibility API in Chrome DevTools.