一、达成的结果
app嵌套h5 加载效率提升了62%。时间从平均2.259s 降到了0.852s
二、优化过程
思路：优化原生webview+h5 ，先测试webview点击到创建时间 120ms（无需优化）。webview 提供了 api 测试 加载url 的进度。但是没提供具体的类似pc端网络的工具。所以就通过ai搜索一些工具。发现阿里云的arms 方便引入。
测试设备 android荣耀50、华为meta9、华为p40、oppo
开发环境测试
测试样本：优化前后各测试10次。
测试移动端h5 引入了阿里云的arms arms.console.aliyun.com/ 可以查看加载某个url的时候 请求的js css、图片、网络请求 跟网页版的网络类似。
php
import ArmsRum from '@arms/rum-browser'
ArmsRum.init({
pid: 'ha63j3v892@efe71d242023cd5',
endpoint: 'https://ha63j3v892-default-cn.rum.aliyuncs.com',
// 设置环境信息，参考值：'prod' | 'gray' | 'pre' | 'daily' | 'local'
env: 'prod',
// 设置路由模式， 参考值：'history' | 'hash'
spaMode: 'hash',
collectors: {
// 页面性能指标监听开关，默认开启
perf: true,
// WebVitals指标监听开关，默认开启
webVitals: true,
// Ajax监听开关，默认开启
api: true,
// 静态资源开关，默认开启
staticResource: true,
// JS错误监听开关，默认开启
jsError: true,
// 控制台错误监听开关，默认开启
consoleError: true,
// 用户行为监听开关，默认开启
action: true,
},
// 链路追踪配置开关，默认关闭
tracing: false,
})
export default ArmsRum步骤一、懒加载echarts
以前的代码
javascript
import Api from '@/api'
import * as echarts from 'echarts'
import dayjs from 'dayjs'
export default {
}现在的代码
javascript
async getRepairChart() {
const echarts = await import('echarts')
// xxx
const chartDom = document.getElementById('repairChart')
const myChart = echarts.init(chartDom)
const option = {
}
myChart.setOption(option)
},通过F12查看网络 发现加载列表的时候有出现echartsxxx.js 而且有800多k ,所以就考虑加载列表不应该去加载数据看板的数据。
优化前，测试前日志打印
平均是3.234s 然后 当然还测试了华为p40 、oppo机器 由于系统不一样时间有些差别
测试后日志打印
平均是1.71s
华为meta9 9年前的老手机打印log
平均也2s多
优化后
不到0.8s
步骤二、禁用预加载、路由懒加载
通过查看网络发现请求dev-haolipei.cias.cn/app/#/takeO... 超级多的js 跟css
一张图都截取不完。当时就感觉肯定请求了很多无关紧要的资源。
npm run build 执行后查看dist目录index.html 的确很触目惊心 加载了太多没必要的资源了。
go
module.exports = {
publicPath,
devServer: {
disableHostCheck: true,
// host: 'localhost.cias.cn',
proxy: {
'/api': {
target,
changeOrigin: true,
// cookieDomainRewrite在手机调试时用得上
// cookieDomainRewrite: '',
pathRewrite: {
'^/api': '',
},
},
'/media': {
target,
changeOrigin: true,
pathRewrite: {
'^/media': '',
},
},
},
},
chainWebpack: config => {
// 禁用预加载
config.plugins.delete('preload')
config.plugins.delete('prefetch')
},
}禁用它们的核心好处
1. 减少不必要的网络请求，节省带宽
- preload 可能会强制加载一些 "非关键资源"（如配置不当的情况下，预加载了体积大但当前页面暂时用不到的资源），导致带宽浪费。
- prefetch 会预加载未来可能访问的路由 chunk（如用户可能不会点击的低频页面），如果用户最终没有访问这些页面，预加载的资源就成了 "无效请求"，尤其对移动端用户（流量有限）不友好。
禁用后，资源仅在明确需要时才会加载（如用户进入对应路由时），避免 "提前加载但用不上" 的浪费。
2. 避免阻塞关键资源加载，提升首屏速度
- 浏览器对同一域名的并发请求数有限制（HTTP/1.1 通常为 6 个）。preload 加载的资源会占用并发名额，可能阻塞当前页面真正需要的关键资源（如核心 JS/CSS），导致首屏渲染延迟。
- 例如：若 preload 预加载了一个 2MB 的非关键 chunk，可能会挤占首屏 JS 的加载带宽，导致页面 "白屏时间" 变长。
禁用后，浏览器的并发资源会优先分配给当前页面的核心资源，减少阻塞。
3. 避免缓存资源被 "无效资源" 占用
浏览器缓存空间有限，prefetch 预加载的大量 "未来可能用到" 的 chunk 会占用缓存空间，可能导致真正需要长期缓存的核心资源（如 chunk-vendors.js）被挤出缓存，下次访问时需要重新加载。
禁用后，缓存可优先保留关键资源，提升二次访问速度。
4. 适配低网速 / 弱网环境
在 3G、偏远地区等弱网环境下，preload/prefetch 的预加载行为会加剧网络拥堵：
- 预加载的资源可能耗时过长，导致当前页面的核心资源加载超时。
- 禁用后，资源加载更 "轻量化"，优先保证当前页面可用，符合弱网环境的用户体验需求。
5. 减少开发环境的冗余加载
在开发环境中，Webpack 会频繁编译资源，preload/prefetch 可能导致每次热更新时加载大量无关资源，拖慢开发服务器响应速度，影响开发体验。禁用后可简化开发环境的资源加载逻辑，提升热更新效率。
注意：并非所有场景都适合禁用
preload/prefetch 本身是性能优化手段，若项目存在以下情况，可能需要保留或部分配置：
- 首屏依赖的关键资源（如核心 CSS、字体）体积大，preload 可加速其加载。
- 高频访问的路由（如首页→列表页），prefetch 可提前加载列表页 chunk，提升跳转速度。
因此，禁用的合理性取决于项目场景：资源体积大、用户网络不稳定、低频路由多的项目（如移动端 H5）更适合禁用；高频路由明确、网络环境好的项目可选择性保留。
路由懒加载
必须写上 /* webpackChunkName: "system-setting" */
以前的代码
css
{
path: '/takeOrder',
name: 'HomeTakeOrder',
component: () =>
import(
'@/views/baosi/orderList.vue'
),
meta: {
title: '推返修列表',
keepAlive: true,
},
}懒加载路由模式
javascript
const HomeTakeOrder = () =>
import(/* webpackChunkName: "take-order" */ '@/views/baosi/orderList.vue')
{
path: '/takeOrder',
name: 'HomeTakeOrder',
component: HomeTakeOrder,
meta: {
title: '推返修列表',
keepAlive: true,
},
},这样的好处 打包后 会有路由名称
对比
继续测试打印log
可以看看网络请求 就只有5个js文件 总体积不到300k
平均是0.852，基本达成要求
通过npm run build 本地打包看看文件对比大小。
1、体积巨减！！！
2、加载的文件名称是路由名称+hash值
优化前
优化后
三、内部项目具体实践
（增值移动端h5项目可以参考以下操作）
1、禁用预加载
go
module.exports = {
publicPath,
devServer: {
disableHostCheck: true,
// host: 'localhost.cias.cn',
proxy: {
'/api': {
target,
changeOrigin: true,
// cookieDomainRewrite在手机调试时用得上
// cookieDomainRewrite: '',
pathRewrite: {
'^/api': '',
},
},
'/media': {
target,
changeOrigin: true,
pathRewrite: {
'^/media': '',
},
},
},
},
chainWebpack: config => {
// 禁用预加载
config.plugins.delete('preload')
config.plugins.delete('prefetch')
},
}2、将路由全部改成懒加载
并且路由需要/* webpackChunkName:"take-order" */
css
{
path: '/takeOrder',
name: 'HomeTakeOrder',
component: () =>
import(
/* webpackChunkName:"take-order" */ '@/views/baosi/orderList.vue'
),
meta: {
title: '推返修列表',
keepAlive: true,
},
}3、组件懒加载
以前常见写法 就是一进来 把所有组件的都加载进来
比如这个车牌号组件有120k 对于比较大一点的组件可以用懒加载 。
arduino
<van-popup v-model="showPlatePopup" position="bottom" :overlay="false">
<keyboard
v-model="baseInfo.plateNumber"
:show.sync="showPlatePopup"
@input="handlePlateInput"
></keyboard>
import Keyboard from '@/components/numberplate/vnp-keyboard.vue'
export default {
name: 'CreateOrder',
components: {
MultiSelectPopup,
DispatchingPopup,
DispatchFailPopup,
DispatchFinishPopup,
Keyboard,
},
}懒加载代码
用这个方式可以直接在网络中查看到对应组件的名称和大小
ini
<van-popup
v-if="showPlatePopup"
v-model="showPlatePopup"
position="bottom"
:overlay="false"
>
<keyboard
v-model="baseInfo.plateNumber"
:show.sync="showPlatePopup"
@input="handlePlateInput"
></keyboard>
</van-popup>
export default {
name: 'CreateOrder',
components: {
MultiSelectPopup,
DispatchingPopup,
DispatchFailPopup,
DispatchFinishPopup,
Keyboard: () =>
import(
/* webpackChunkName: "keyboard" */
'@/components/numberplate/vnp-keyboard.vue'
),
},
}还有 特别大的第三方库 echart 懒加载 按需引入
四、总结
目前通过禁用预加载、路由懒加载、和第三方组件懒加载使用方式 基本能达到很大程度的优化效果。
但是看图 每次加载前面2个文件一个683k 另外一个285k 还是压缩了的文件 ，
我猜应该是main.js 引入了很多东西，后续还可以有优化空间。移动端的h5 入口文件尽量简洁。
(自己写的页面 一定多注意看一下 网络 有多少个js 和css 图片) 资源过大就要考虑优化了。
性能优化一定要多测试验证、多测试验证、多测试验证，保证业务正常情况下优化性能。
性能优化参考。