我把数据复盘了一遍：新91视频为什么有人用得很顺、有人总卡？分水岭就在分类筛选（不服你来试）
我把数据复盘了一遍：新91视频为什么有人用得很顺、有人总卡？分水岭就在分类筛选（不服你来试）
引子 很多人抱怨“新91视频”播放或浏览时体验悬殊——同事A浏览顺滑、同事B卡顿频繁。把产品、前端、后端、网络和内容端都翻了一遍后，最明显的分水岭并不是设备好坏，而是“分类筛选”这一环节的处理方式。下面把数据和可复现的排查步骤、优化建议一并列出来，你可以直接照着试。
一、我看了哪些数据
- 接口响应时间（首包/完全加载）按分类统计；
- 单页面视频列表渲染耗时（DOM、图片、脚本）；
- 客户端平均缓冲时间与掉帧率（移动端/PC 分别统计）；
- 后端查询耗时（按分类、分页、排序）；
- 网络负载与CDN命中率。
直观结论：某些分类的接口返回体积、数据库查询开销和前端渲染复杂度都显著高于其它分类，导致体验恶化。也就是说，分类本身成为了性能分水岭。
二、为什么分类会造成差异（几个核心原因） 1) 单分类内视频密度与元数据复杂度：某些分类含大量长标题、标签、推荐信息，响应体变大，解析与渲染成本上升。 2) 后端查询没有按分类优化索引：数据库全表扫描或排序在大分类上变慢。 3) 客户端渲染策略不同：有的分类默认预加载大量缩略图或视频帧，图片未做懒加载/压缩。 4) 内容本身编码与CDN分布：高码率或未转码的视频在特定分类集中，CDN缓存命中率低。 5) 交互逻辑不同：某些分类触发了额外的推荐或统计埋点，导致多次网络请求阻塞渲染。
三、如何自己复现并验证（按步骤） 1) 按分类抓取接口：
- 用 curl 或 Postman 拉取 /videos?category=X&limit=50，记录 response size 与 time_total。 2) 浏览器侧测量：
- 打开 Chrome DevTools → Network，切换不同分类，观察请求数、耗时、资源大小。
- Performance 面板录制一次交互，查看长任务（>50ms）、首次内容绘制时间。 3) 视频层面检测：
- 使用 ffprobe 检查样本视频的码率、分辨率与编码（h.264/h.265）。 4) 后端查询耗时：
- 在数据库开启慢查询日志或在应用层记录 SQL 执行时间，按 category 分组统计平均时长。 5) 客户端指标对比：
- 收集各分类的平均缓冲时间、掉帧率（通过埋点或浏览器 API），形成对比表。
四、实用优化清单（按优先级） 后端
- 给分类字段加复合索引（例如：CREATE INDEX idxcatstatuscreated ON videos(categoryid, status, created_at)），避免全表扫描。
- 分页采用基于游标的方式替代 OFFSET LIMIT，处理大分类时避免跳页成本。
- 对热分类开启缓存（Redis/HTTP缓存）并预暖，设置合理 TTL。
CDN与转码
- 强化转码策略：对高码率视频做多分辨率切片，按客户端能力下发合适码流。
- 优化 CDN 缓存策略，尽量将热门分类的视频缓存靠近用户端。
前端
- 缩略图与视频资源启用懒加载和占位图，避免初次渲染拉取全部资源。
- 列表采用虚拟滚动（virtualization）减少 DOM 节点。
- 将非关键请求（推荐、统计）设为异步延后加载，不阻塞首屏渲染。
- 压缩 JSON 响应，移除不必要字段，按需下发元数据。
观测与回归
- 对每一项优化做 A/B 测试，统计关键指标：接口 P95 响应、首屏时间、缓冲次数、跳出率。
- 建立分类维度的性能仪表盘，长期监控并设置告警阈值（例如 P95 接口 > 800ms、缓冲率 > 5%）。
五、简单实验（可直接跑）
- 对比实验：选两个分类 A（小）与 B（大），分别在同一网络与设备上重复 30 次打开列表并记录：
- 平均接口耗时、响应体大小；
- 首次内容绘制（FCP）；
- 平均缓冲次数。 如果 B 的这些指标显著高于 A，分类问题成立。
结语 分类看似只是一个筛选选项，但一旦和数据规模、后端查询、前端渲染、CDN缓存挂钩，就能放大成明显的体验差异。先把“分类维度”的数据链路梳通，再去调细节，能最快见到效果。要不要现在就挑两个分类按上面的步骤跑一遍？跑完把结果贴上来，我帮你看数据并给出更针对性的优化建议。
下一篇：没有了
