5 分钟阅读
性能已经成为设计的一部分
页面体积、图片选择、JavaScript 和动画都会影响设计体验,Core Web Vitals 让这些取舍在移动网络下更容易被发现。性能需要进入版式和交互审核,而不是等网站上线前才由开发人员补救。
设计稿不会显示加载成本
页面在设计稿里可能很简洁,但加入大图、多套字体、动画库和第三方脚本后仍会变慢。性能审核需要基于真实页面、接近发布的内容,以及访客常用的设备和网络条件。
在布局仍然灵活的情况下商定页面预算。预算可以涵盖必须为第一次查看准备好的英雄图像、字体文件、第三方脚本和交互代码。然后,设计人员可以决定哪些视觉元素具有足够的价值来证明其加载和渲染成本的合理性。
按模板和设备设置性能预期。主页、服务页面、文章和应用程序屏幕的内容不同,因此一条快速路线无法代表整个网站。更改前后使用相同的测试条件,并将结果与页面版本保持一致。实验室测量有助于诊断,而现场数据则反映实际访客的情况;不应在不解释其来源和覆盖范围的情况下引用两者。
围绕页面主要动作安排优先级
把首屏内容、媒体和脚本放在一起评估,不把速度留到最后处理。
首屏标题、主要图片和核心操作通常需要最早加载。页面下方的媒体和可选交互可以稍后处理,让访客在浏览器继续加载其他资源时已经能理解页面并开始操作。
加载顺序遵循访问者的任务。服务页面通常需要在图库或嵌入地图之前提供标题、报价和主要操作。一篇文章在装饰媒体之前需要可读的文本。将每个图像标记为紧急会争夺相同的连接,并且可能会延迟最重要的元素。
优先级从理解页面所需的内容开始。主要标题和基本文本不应等待可选脚本。为可能最大的可见图像提供正确的尺寸和传送优先级,然后进一步延迟加载媒体。避免将每个图像标记为紧急。在文章和目录页面上,可以显示可读结构,同时继续加载辅助图像、推荐或嵌入式服务。
分别审核图片、字体和 JavaScript
在常见移动网络条件下检查复杂动画和第三方嵌入的实际成本。
图片、字体和 JavaScript 带来的成本不同。图片要控制尺寸和格式,字体要选择必要字重和字符集,JavaScript 则需要明确用途。只看一个总分很难找到真正有效的修改。
绩效工作应该找出一个原因,而不是追求一个分数。服务器响应缓慢、英雄图像过大、字体阻塞和 JavaScript 任务过长需要不同的修复。比较来自相同路线和设备配置文件的跟踪,然后验证更改是否改善了访问者的体验,而无需删除所需的功能。
字体和动画也会影响感知速度。限制族和权重,仅加载必要的字符集并提供具有兼容指标的后备。动画代码应在所需布局存在后运行,并尊重简化运动首选项。检查固定或变换的部分是否会在移动设备上创建较大的绘制区域。目标是保持预期的视觉方向,同时删除对访问者任务无益的工作。
在常见移动端条件下测试首次访问。
同时测试首次无缓存访问和后续刷新,并在移动端检查布局移动、交互延迟和首屏最大元素。轻量测试页速度快,并不能证明图片较多的服务页或文章页也有同样表现。
实际检查
- 在发布检查中保留一小组代表性页面:主页、媒体密集型服务页面、文章以及任何形式或商店旅程。新内容和第三方工具可能会在启动后改变性能,因此当模板、跟踪或主要资产发生变化时,应再次检查这些页面。
开发前确认性能和验收检查,完成后才能在真实设备上验证结果。
包括发布和内容工作流程中的性能。编辑者可以通过上传超大图像或嵌入多个外部小部件来取消精心开发。记录图像尺寸、视频处理和批准的第三方工具。模板、跟踪或营销活动更改后重新检查代表性页面。当出现回归时,记录负责的资产或脚本,以便修复是特定的,并且不会成为简化整个设计的一般请求。
相关服务