从逻辑上讲，“更快”的页面就是“更好”的页面。他们做事更快，搜索引擎优化得分更高，消耗更少的能量，人们喜欢他们。这就是我如何在mybuilder.com上找到一个对SEO很重要的页面，并将其指标减半的方法。

“快”是什么意思?

页面加载在web性能社区中被认为是一个“遗留指标”。这是因为网页不再只是HTML，所有东西都被解析解压缩，更多的东西被下载。因此，在实践中，较低的“页面负载”数字并不一定与良好的用户体验相关。

的第一和最大的内容油漆这是两个更好的衡量标准，当试图使一个页面“感觉上快”和客观上快时。

您应该做的第一件事是在开始之前对页面的位置进行盘点。一个简单的方法是使用chrome内置灯塔特色或打开一个SpeedCurve帐户和熟悉仪表盘。这将给你一个概览和进度记录，但为了了解你的努力集中在哪里，你需要具体了解什么是下载、加载、呈现和请求;以及它们发生的顺序。

瀑布

你可以让Chrome绘制一个网页流量的程序图，在网络性能圈中被称为“瀑布”，因为当表格按默认的“时间开始”列排序时，它的外观是向下和向右的。

要在chrome浏览器中浏览到你的页面瀑布，然后:打开网络选项卡，在开发人员工具中勾选“禁用缓存”，选择一个不太完美的网络条件，例如“快速/慢速3g”，然后点击刷新页面。

当瀑布完成时，你应该能够看到道具是如何聚集在一起形成明显的瓶颈。

由于我是网络性能世界的新手，我有两个主要的策略来加快页面速度，第三个由MyBuilder SRE团队负责:

• 少拥有一些东西
• 重新排序的东西
• 更快的服务器

少拥有一些东西

从上到下阅读瀑布上的项目。你可能会注意到在你的图表上放宽图表的3个常见因素:图像、字体和JavaScript。

图片

如果图像由于某种原因不可见，试着找到它并删除违规代码。此外，考虑删除任何不符合页面目标的图片。

压缩你的图像，如果你不能明显地看到你的jpeg上的压缩工件，你是压缩不够努力。你会看到讨厌的方块，但真正的用户可能看不到。对于png格式的文件，通过png压缩器运行它们，该压缩器采用“无损”格式，并对比特应用类似于gzip的压缩，这将使带有许多扁平颜色的图像在文件大小上显著缩小。svg通常本质上很小，但可以通过SVGO瘦下来。

一旦您压缩了图像，请确保您为较小的设备提供了适当的大小。在MyBuilder.com上，我们使用Symfony和一个twig函数来查看请求，并有条件地向“移动”用户代理提供更小的图像。你也可以用modern来做响应的图像HTML，这可能更好，但超出了本文的范围。这种更新的HTML标记将为浏览器提供一组图像的选项和规格，以便它可以根据当前条件决定需要哪个图像。

HTML中的图像在第一批中被请求，因为HTML从初始服务器请求返回，但CSS中的图像只有在解析DOM和CSSOM(可以阻止或强制通过脚本重新评估)后被认为是可见的情况下才会显示。这意味着放置在CSS背景图像中的图像最终会相对较晚出现。

字体

web字体会降低页面的速度。仔细看看你是否都需要。确保你所拥有的资源与你的其他资源位于同一位置。这意味着客户端已经预先连接，并且可以使用HTTP2。

Javascript

这一点就不那么直接了。这意味着要正确地审视你所包含的内容以及你所使用的内容。如果包含了jQuery，这是一个很好的开始，但如何删除它超出了本文的范围。

如果您不能删除一个脚本，请确保它在正确的位置。传统的逻辑是在文档Head中有供应商脚本，在页面内容之后有“自定义”脚本。这样做的原因是头部的脚本将在呈现页面之前被下载和解析，但之后的脚本将在浏览器到达该行时被下载，这将阻塞页面解析，直到脚本运行。实现这一目标的更一致的方法是在脚本标签中添加' async '或' defer '属性。' Async '将停止阻塞，但仍会尽快运行，' defer '将等待页面完成解析。

在您删除了谨慎的脚本之后。如果你有一组javascript在构建时捆绑在一起，你就有机会在构建系统中添加有效负载减少。Webpack、Rollup、Parcel和其他流行的工具都有摇树、代码拆分和范围提升的选项。

Tree-shaking将分析您的代码，只包含被调用的函数或作用域，而丢弃其余的。如果你包含了像下划线。js这样的东西，那就太好了。

代码分隔将编译后的代码分成多个包(文件)，这些包可以单独缓存，但更重要的是，可以并发下载。

范围提升是一种较新的方法，类似于模块绑定器，但会在应用一些重命名以避免冲突后，将模块放入单个函数中。这意味着文件更小，但结构更简单，使用的内存更少，解析速度更快。

再订购的东西

当页面看起来可以更快地使用时，快速页面的感觉就会提高。有时这意味着将初始加载向后移动，以避免显示未准备使用的内容。

预取

当背景图片开始下载时CSSOM已经被解析，样式已经被应用，页面正在呈现。这将出现为图像保留的空间，它将在加载时弹出。这不仅看起来很糟糕，而且它将“最后的令人满意的痛苦”往前推了一步。

为了防止背景图像弹出，我们可以通过添加“预取链接”让浏览器意识到我们将很快需要这个图像。在MyBuilder.com上，我们想要使用的图像被提供给Twig模板，然后放入样式标签中，所以我们也添加了一个到页面头部的预取链接。

预加载

默认情况下，页面将在所有资产完成下载之前开始呈现页面。在(大)网页字体的情况下，这通常会导致无样式文本的Flash (FOUT)，这可能会导致布局的转移。为了解决这个问题，你可以告诉浏览器等待，直到字体被加载后再开始，通过添加一个预加载链接，以确保客户端在试图渲染页面之前获得资产，通过添加一个预加载链接到资产。

<链接rel =“预”href =“https://www.example.com/assets/fonts/example-webfont.woff2”是=“字体”crossorigin =＂＂类型=“字体/ woff2”>

这将推迟你的初始渲染，但通常会产生更好的用户体验。你必须自己做出权衡取舍的决定。

延迟加载

这取决于浏览器来决定图片需要下载的顺序。传统的顺序并不一致，也不实用，这意味着页脚中的图片可能优先于页面顶部的图片。现代浏览器更擅长查看图像出现在DOM中的位置，但它们并不完美或一致。延迟加载使图像对初始解析不可见，然后在页面加载后使用javascript将其交换。

< imgsrc =“小图像占位符”data-lazyimgdata-src =“资产/图片/ real-image.jpg”/>

这可以应用到任何你认为不需要初始渲染的图像。

延迟加载

当延迟加载应用一个通用规则时，Lazy加载尝试在加载图像时更聪明。本质上，它是延迟加载与事件监听器的结合，等待资产滚动到视图中，然后加载它。不过，必须考虑所需的javascript和用户体验之间的权衡。在我们的mybuilder.com页面上，当用户单击将图像带入视图的按钮时，我们手动将图像传递给惰性加载器。

更快的服务器

我已经谈到了HTTP/2。这种“更新的”协议可以从一台主机上同时下载更多的东西。在过去，客户机会很快达到极限，必须等待才能从同一主机获得更多资产。为了解决这个问题，一种名为“分片”的托管技术将你的资产分布在多个服务器上，这样客户端就可以一次获得更多资产。在HTTP/2中，这种逻辑不再适用，你最好把所有东西都放在一个地方。必须确保提供程序/服务器配置正确，否则客户机将恢复到HTTP/1。在MyBuilder中，我们使用Cloudfront作为我们的内容交付网络(又名CDN)，它将在相关的存在点(又名POP)缓存内容。这意味着用户将能够从地理位置上离他们最近的服务器获取内容。

结论

我仍然是网页性能的新手，但在做了上面的改变后，页面的速度大约是原来的两倍，“第一次内容绘制”从8.32秒增加到3.38秒。