Nuxt 3 企业官网性能优化的七个实践要点

企业官网的性能问题通常不是由某一个“大文件”造成，而是许多小决策叠加的结果：所有页面使用同一种渲染方式、首屏加载整套组件库、图片只有一个尺寸、字体包含大量不用字符、统计脚本阻塞主线程。Nuxt 3 提供了良好基础，但框架不会自动替代工程判断。

第一，按页面选择渲染策略。首页、服务、案例和文章等公开内容通常适合服务端渲染或预渲染，以获得稳定首屏与搜索可见性；高度个性化、依赖登录态的后台页面可以偏向客户端。不要为了“统一”让所有页面承担相同成本，也不要在没有业务需求时把每次访问都变成动态计算。

第二，建立图片规则。根据卡片、详情头图和移动端场景输出合适尺寸，优先使用现代格式并保留回退。首屏主图应明确尺寸、合理预加载，非首屏图片延迟加载。object-fit 只能解决展示方式，不能替代正确的源图比例和中央安全区设计。图片中尽量不嵌入重要文字，以免裁切和无障碍访问受影响。

第三，减少不必要的客户端 JavaScript。纯展示模块优先由服务端输出，不要因为一个简单交互让整块内容都依赖水合。大型图表、编辑器、地图或视频组件按需加载；全局插件只注册真正全站需要的能力。拆包并非越碎越好，应结合访问路径控制请求数量与执行成本。

第四，谨慎处理字体。优先使用系统字体或经过裁剪的品牌字体，明确 font-display 策略并设置合适回退，减少字体加载前后的布局跳动。图标建议采用轻量 SVG 组件，不要为了少量图标加载整套字体文件。

第五，建立缓存层次。带哈希的静态资源可以长期缓存，内容页面根据更新频率设置策略，接口数据则区分公开、个性化和实时场景。配合 CDN 时，要明确哪些响应可以共享，避免把用户相关内容错误缓存。部署后通过响应头验证，而不是只看配置文件。

第六，控制第三方脚本。客服、统计、广告和行为分析工具会竞争网络与主线程资源。团队应明确每个脚本的业务价值、加载时机和失败影响，非必要脚本延后加载，并定期清理已经停用但仍留在页面中的代码。

第七，使用真实访问数据持续监测。实验室测试适合定位问题，真实用户数据则能反映设备、网络和 WebView 差异。除首屏速度外，还应关注交互响应、布局稳定、接口失败和关键业务路径。性能预算可以纳入发布检查，防止项目在持续迭代中逐渐变慢。

优化的目标不是追求一次测试的满分，而是在内容丰富、视觉完整和业务工具可用的前提下，让多数用户稳定、快速地完成任务。性能应从设计和架构阶段进入决策，而不是上线前最后一次压缩。