企业网站为什么会变慢

衡量真实访问量

主页在开发人员笔记本电脑上感觉很快，但对于第一次没有缓存的移动访问者来说却很慢。实验室工具可以揭示请求和渲染成本，而现场数据可以显示真实的访问者是否体验到相同的模式。

测试代表性模板、首次访问和重复导航；分别记录加载、交互和布局行为。

首先在重要的页面上进行可重复的测量。记录设备配置文件、网络状况、缓存状态和确切路由，然后检查服务器响应和加载顺序。在办公室宽带上测试的主页可能会隐藏电话上遇到的延迟。每次更改后比较相同的设置。这使得可以将真正的改进与不相关测试之间的正常变化区分开来。

检查图像和字体

超大图像和未使用的字体文件通常会在访问者阅读或操作之前消耗带宽。尺寸正确的现代图像和较小的字体粗细可以减少工作量，而无需更改已批准的设计。

将渲染的尺寸与下载的尺寸进行比较，并列出首屏上方请求的每个字体文件、粗细和子集。

介质问题通常在请求列表中可见。检查主图像是否在接近其显示尺寸的情况下交付，非首屏图像是否等到需要时才显示，以及视频是否有有意的加载策略。现代格式有所帮助，但正确的大小和优先级也很重要。被压缩但比其渲染区域大几倍的图像仍然使用带宽和解码时间，访问者无法从中受益。

JavaScript 和第三方的帐户

分析、聊天、视频、同意和动画脚本争夺浏览器的主线程。一个小的可视化小部件可能会下载多个包或在其自己的界面出现后很长时间内延迟交互。

将每个脚本映射到所有者和业务目的；推迟、替换或删除不支持页面主要任务的代码。

JavaScript 和第三方工具需要单独审查。标签管理器、聊天小部件、同意系统、地图和动画库可以与页面自己的交互代码竞争。在访问者执行操作之前，确定哪个脚本拥有每个长任务以及是否需要它。延迟可选工具、删除重复项并测试当提供程序速度缓慢或被阻止时页面是否仍然有效。性能不应取决于每个外部服务的完美响应。

首先修复最大的已验证原因

仅凭分数并不能告诉团队哪些更改将改进特定页面。删除一个阻塞请求可能比几十个小的压缩更改更重要。

修复属于责任层。缓慢的 HTML 可能需要服务器或数据工作；后期的主图像可能需要预加载和尺寸更改；布局移动可能来自尺寸或字体缺失；延迟的点击可能来自于大量的客户群。在建议的更改旁边写下原因并重新测试受影响的模板。通过从页面的不同部分删除有用的内容来避免隐藏未解决的瓶颈。