mcpField
W
web-performance

web-performance

github.com/alexanderstephenthompson开发48 次安装
代码仓库

关于 web-performance

web-performance 是一项面向使用 Apollo、Redis、CloudFront 和 S3 的 Web 应用性能技能。内容涵盖缓存、载荷与代码包精简、React 渲染及数据库查询优化。

主要功能

  1. 01Apollo Client 缓存策略
  2. 02Redis 缓存与失效模式
  3. 03CloudFront 和 S3 资源缓存
  4. 04按路由拆分代码
  5. 05React 渲染优化
  6. 06数据库查询与索引建议

适用场景

  1. 01为变化数据和静态数据设置缓存策略
  2. 02缩减初始 JavaScript 代码包
  3. 03通过 CloudFront 和 S3 优化图像传输
  4. 04排查缓慢数据库查询和 N+1 访问

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/alexanderstephenthompson/claude-hub --skill web-performance

安装后在 Claude Code 中输入/web-performance确认已加载。

附带文件assets/caching-patterns.mdassets/optimization-patterns.md

详细介绍

Web 性能技能

版本： 1.0 技术栈： Apollo Client/Server + Redis + CloudFront + S3

开发过程中，性能问题往往难以察觉。本地服务器运行很快。测试数据量也很小。直到真实用户在真实网络环境中使用真实数据，反馈页面需要 8 秒才能加载时，你才会发现 3MB 的打包体积、N+1 查询或全表扫描。到了那时，你就不得不顶着压力，一次性重构缓存层、拆分打包文件并重写查询。

从一开始就应用性能模式，成本很低。上线后再修复性能问题，成本就很高。以下规则能以较低成本避免这些问题。

核心原则

  1. 先测量 — 优化前先进行性能分析。不要凭猜测。
  2. 每一层都缓存 — CDN → API → 数据库 → 内存。
  3. 尽量减小负载 — 只发送所需内容。
  4. 延迟加载非关键内容 — 先加载关键路径，其余内容稍后加载。
  5. 提升感知性能 — 乐观 UI 能让操作感觉更快。

Core Web Vitals 目标

指标衡量内容目标临界值
LCP (最大内容绘制)主要内容加载情况< 2.5s< 4s
INP (交互到下一次绘制)输入响应速度< 200ms< 500ms
CLS (累积布局偏移)视觉稳定性< 0.1< 0.25

Apollo Client 缓存

为 InMemoryCache 配置类型策略，以合并分页数据并处理计算字段。默认使用 cache-and-network 获取策略（先使用旧数据，再重新验证）。对变更使用乐观更新，让 UI 操作感觉即时生效。

获取策略
策略使用场景
cache-first静态数据（类别、配置）
cache-and-network会变化的数据（商品、用户数据）
network-only始终获取最新数据（订单状态、实时数据）
cache-only离线模式、已知存在缓存的数据

有关缓存配置、获取策略示例和乐观更新模式，请参阅 assets/caching-patterns.md。

Redis 缓存

采用旁路缓存模式：检查缓存 → 未命中 → 获取数据库数据 → 存入缓存。写入时使缓存失效。列表查询使用基于标签的失效策略。

TTL 指南
数据类型TTL原因
静态配置24h+很少变化
商品目录1h偶尔变化
用户会话30m平衡安全性
购物车数据7d方便用户
搜索结果5m平衡新鲜度与速度
实时数据不缓存必须保持实时

有关 Redis 缓存服务、旁路缓存模式和失效示例，请参阅 assets/caching-patterns.md。

CloudFront 与 S3 优化

不可变资源（带哈希的文件名）设置 365 天缓存。API 路由不使用 CDN 缓存。图片按需调整尺寸，采用 WebP 格式、延迟加载，并为视网膜屏幕提供 2x srcSet。

有关 CDK 配置和图片优化组件，请参阅 assets/caching-patterns.md。

打包优化

使用 React.lazy 按路由拆分代码。对大型库使用动态导入（仅在需要时加载）。使用 source-map-explorer 进行分析。

打包体积指南
类别目标超出后的处理方式
初始 JS< 100KB（gzip 后）拆分代码、摇树优化
Vendor 分块< 150KB（gzip 后）延迟加载、寻找替代方案
路由分块< 50KB（gzip 后）进一步拆分
初始加载总量< 200KB（gzip 后）审查依赖项

有关代码拆分、动态导入和打包分析示例，请参阅 assets/optimization-patterns.md。

React 性能

使用 useMemo 执行开销较大的计算，使用 useCallback 稳定传递给已记忆化子组件的回调，并对列表项组件使用 memo。不要对简单值、总在变化的值，或传递给未记忆化子组件的处理函数进行记忆化。对于较长的列表（100 项以上），使用虚拟化。

有关记忆化、何时不应进行记忆化以及虚拟化的示例，请参阅 assets/optimization-patterns.md。

数据库性能

只选择所需字段。谨慎使用 include。对于复杂聚合，使用原生查询。在用于筛选或排序的列上添加复合索引。

有关 Prisma 查询优化和索引策略，请参阅 assets/optimization-patterns.md。

反模式

反模式问题修复方法
获取所有字段获取过多数据，速度慢只选择所需字段
不使用分页内存问题，速度慢基于游标的分页
缓存所有内容数据过期，复杂度增加按 TTL 有策略地缓存
过早优化浪费精力先测量，再优化热点
同步执行繁重操作阻塞响应使用后台任务（Bull）
静态资源未使用 CDN全球交付速度慢使用 CloudFront 分发静态文件
图片未经优化下载量巨大调整尺寸、压缩并使用 WebP
阻塞式打包初始加载缓慢拆分代码、延迟加载

检查清单

前端
  • 按路由拆分代码
  • 延迟加载大型库
  • 延迟加载图片
  • 优化图片（WebP、调整尺寸）
  • 初始包体积 < 200KB
  • 在有益的情况下使用 useMemo/useCallback
  • 对长列表进行虚拟化
Apollo
  • 配置缓存策略
  • 正确合并分页数据
  • 为变更操作启用乐观更新
  • 获取策略符合数据新鲜度需求
Redis
  • 缓存热点数据
  • TTL 适合数据类型
  • 更新时使缓存失效
  • 配置连接池
数据库
  • 在用于筛选或排序的列上建立索引
  • 只选择所需字段
  • 消除 N+1 查询（DataLoader）
  • 分析开销较大的查询
CDN
  • 在 CloudFront 上托管静态资源
  • 永久缓存不可变资源
  • 不在边缘缓存动态内容
  • 强制使用 HTTPS

何时考虑替代方案

情况可考虑
全球实时数据Redis Pub/Sub 或 WebSockets
计算开销较大后台工作进程（Bull）
大文件上传直接使用 S3 预签名 URL
搜索需求较多Elasticsearch 或 Algolia
需要边缘计算CloudFront Functions 或 Lambda@Edge

参考资料

  • assets/caching-patterns.md — Apollo 缓存配置、Redis、CloudFront、图片优化
  • assets/optimization-patterns.md — 包拆分、React 记忆化、虚拟化、数据库优化

评论

支持 Markdown