为什么你的H5一打开就卡？先看这3个真实问题
用户点开页面3秒内走人，不是内容不行，是加载慢得像拖拉机。你可能觉得“再优化一下就好”，但现实是——很多人根本没机会看到你精心设计的动效。
更扎心的是：在红米、荣耀、realme这些百元机上白屏、闪退、卡成PPT，旗舰机却丝滑如油。这不是“偶发”，是低端机的底层能力压根扛不住堆料。你写的代码，对它们来说就是一场酷刑。
打包后体积超过30MB，依赖全量引入，图片资源乱塞，压缩没做，代码冗余严重……别再拿“这是常规操作”当借口了。这些不是“优化建议”，是必须绕开的坑。只要主包控制在11MB以内，再配合基础适配，十有八九能跑通低端安卓机——但前提是：你得知道哪些东西不能碰。
第一步：把打包体积压到11MB，必须做对这5件事
1. 用 Webpack 5 分包 按需加载，别让依赖吃掉一半体积
splitChunks 必须配置，把 node_modules 单独拆成 vendor.js，不然每次更新都得全量重传，用户哭都来不及。
再说一遍：别写 import { Button } from 'element-plus' 这种写法，它会把整个库打包进来，等于白送用户一堆垃圾代码。
正确做法是：
import Button from 'element-plus/lib/button'
但注意，有些组件路径不在 lib/ 目录下，得自己翻源码确认，不然编译报错，一脸懵。
还有 lodash，别 import * as _ from 'lodash'，直接按需导入：
import debounce from 'lodash/debounce'
✅ 实测：一个活动页从 34MB 压到 8.6MB，靠的就是拆分 精准引入。但代价是：每个组件都要手动检查路径，容易漏掉，出错率高，我见过同事因为少导一行代码，上线后被客户投诉“打不开”。
2. 图片和字体资源要“瘦身”
所有图片转成 webp，比 jpg 小 30%~50%，听起来很美，但部分低端机（尤其是2016年以前的）根本不支持。必须加 fallback，否则用户看到一片空白，还以为你服务器挂了。
图片大于 10KB 就用 asset/resource，别内联成 base64 —— base64 会让 JS 文件暴涨，还无法缓存，简直是自找麻烦。
字体文件（.woff2）也走 asset/resource，别塞进 JS，否则首屏加载直接阻塞。
关键动作：用
gulp-svg-sprite或webpack-svgstore-plugin合并小图标，别手动拼图，否则维护成本爆炸。
⚠️ 警惕：某些品牌机（如魅族旧款）解析大尺寸 sprite 时会崩溃，建议单张不超过 512×512。
3. 启用压缩工具：Terser CssMinimizer
terser-webpack-plugin 必须开启 parallel: true，压缩速度翻倍，省时间。
关闭注释输出，去掉 comments: false，否则体积降不下来。
css-minimizer-webpack-plugin 去除无用样式，但有个坑：它不会删掉被动态注入的类名，比如通过 JS 添加的 .active，可能误删，结果页面功能崩了。
配置示例：
optimization: {
minimizer: [
new TerserPlugin({
parallel: true,
extractComments: false,
terserOptions: { format: { comments: false } }
}),
new CssMinimizerPlugin()
]
}效果：代码压缩率提升约 25%。但部分混淆后的变量名会变成
a,b,c，调试困难，建议保留 sourcemap 用于排查。
（我曾经为一个线上崩溃问题查了整整两天，最后发现是变量名太短导致定位不到）
4. 拒绝大体积依赖，定期“瘦身日”
每月搞一次“代码瘦身日”：清理未使用的依赖、删除僵尸组件。
用 depcheck 工具扫描，找出未使用依赖，但注意：它常误判动态导入的模块，需要人工核对。
在 CI 流程中加体积检查：
# 主包 ≤ 1MB，超了就失败 if bundleSize > 1024*1024; then exit 1; fi
PR 提交强制附带 webpack-bundle-analyzer 报告截图，别省这一步，线上出事才后悔。
⚠️ 有人嫌麻烦？等用户投诉“打不开”“卡死”“闪退”时，就知道“省事=出事”。
（我见过一个项目，上线后3天流失70%用户，原因竟是一个没人用的统计脚本占了1.2MB）
5. 用 CDN 加速静态资源
将 vue、react、lodash 等通用库通过 CDN 引入，不打包进主包。
配置 externals：
externals: {
vue: 'Vue',
'lodash': '_'
}HTML 中手动引入：
结果：主包从 15MB 降到 7.2MB，首屏加载快 2 秒。
❗ 但风险：CDN 可能失效或被墙，必须加本地备用方案，比如：
第二步：适配低端安卓机，不能只靠“好看”
1. 视口设置要动态，别用死板的 viewport=width=device-width
这种写法，在高端机上没问题，但在低端机上会导致缩放异常，边框模糊，体验差到离谱。
正确做法是：用 lib-flexible 动态设置缩放比例，保持 1px = 1 物理像素。
安装方式：
npm install lib-flexible
入口文件加入：
import 'lib-flexible/flexible'
✅ 效果：在骁龙410、联发科P20等低端机上，边框清晰不模糊。
⚠️ 但注意：部分国产机（如小米、OPPO）系统级浏览器会屏蔽flexible的动态计算，必须加window.onload事件兜底。
2. 禁止使用复杂动画与大背景图
别碰 transform: translateZ(0)、opacity 动画这些触发重绘的属性——低端机渲染引擎跟不上，一上就卡死。
背景图用 background-image background-size: cover，别用
复杂动效用 requestAnimationFrame 控制帧率，限制在 20~30fps，避免 60fps 跑不动。
低端机跑不了 60fps，一上就卡成“呼吸灯”。
❗ 有真实案例：某活动页用了 3 个opacity动画叠加，结果在红米6上卡到无法点击，用户直接关页走人。
3. 页面结构要极简，避免嵌套过深
最多 3 层嵌套，别搞 div > div > div > div > ... 这种地狱级结构。
用语义化标签替代 div，如 header、section、button，减少解析负担。
表单控件用原生 input，别用自定义组件模拟——自定义组件通常绑定事件多、层级深，容易引发内存泄漏。
❗ 有些低端机解析 50 层嵌套时会崩溃，真有客户反馈“点不动”，排查发现是组件树太深。
（我当时以为是网络问题，结果一查是结构太深，当场脸红）
第三步：兼容性处理，别让“细节”毁掉用户体验
1. iOS 输入框光标高度异常？
原因：height 与 line-height 不一致，iOS 自动拉高光标。
解决方法：
input {
height: 40px;
line-height: 40px;
padding: 0;
box-sizing: border-box;
}别设 padding-top、padding-bottom，否则光标还是高。
✅ 实测：在 iPhone 7 上有效，但 iPad mini 4 仍可能异常，需单独测试。
2. iOS 自动播放音视频失败？
原因：Safari 严格禁止自动播放，尤其在静音状态下也不行。
解决方法：
video.play().catch(() => {
document.getElementById('playBtn').style.display = 'block';
})用按钮触发播放，别指望自动播。
关键：必须让用户主动点击，否则永远无法播放。
3. 触摸事件卡顿？加 touch-action: manipulation
.btn {
touch-action: manipulation;
}防止浏览器默认滚动干扰点击，尤其在输入框附近。
✅ 有效，但注意：某些老版本 Android WebView（低于 4.4）不支持
touch-action，需加preventDefault()作为兜底。
常见问题（FAQ）
Q：11MB 是怎么算的？包括图片吗？
A：指 main.js vendor.js common.css 总体积，不包含图片/字体等静态资源。若含资源，建议整体控制在 15MB 内，否则低端机加载压力大。
Q：低端安卓机最低支持到哪一代？
A：骁龙410、联发科P20、MTK6750 这类 2016 年左右的芯片基本能跑通，内存 ≥ 1.5GB。低于 1.5GB 内存的机型，建议放弃此方案，改用纯静态页或 H5 原生壳。
Q：必须用 Webpack 吗？Vite 可以吗？
A：可以，原理一样。只需配置 splitChunks、assets 分离、按需引入即可。但 Vite 的热更新快，打包体积略大，需额外优化。
Q：我用 H5 搭建活动页，怎么保证不流失用户？
A：先压包到 11MB，再做基础适配（视口 输入框 动画），最后用真机测试。别用模拟器，模拟器跑得顺，真机不一定。
Q：有没有现成模板？
A：有。可参考 lib-flexible Webpack5 优化配置 搭建骨架。
但别照搬，每个项目环境不同，必须自己调参。
业内共识与平替方案
主流做法：多数企业采用“轻量 H5 原生壳”模式，用 WebView 加载页面，核心功能用原生实现。
优点：性能稳，兼容性好。
缺点：开发成本高，不适合快速上线的活动页。
平替方案：如果预算低、周期短，直接用 纯静态页（HTML CSS JS） CDN，不打包、不依赖，体积压缩到 2MB 以内，低端机也能秒开。
项目周期 ≤ 3 天
团队只有 1 个前端
预算低于 5 万元
→ 直接放弃，用静态页，省心省力。适合：宣传页、抽奖页、落地页。
劝退指南：如果你属于以下情况，别折腾轻量化：
