如何在WordPress中提高PageSpeed

我们从Google那里听到了很多有关PageSpeed的信息，毫无疑问，从可用性和SEO角度来看，这是一个重要的指标。 当然，除了WordPress之外，网络上还有更多的东西，但是现在它已经为59.3％的网络提供了强大的功能，而Google专门成立了一支工程团队来使用WordPress，因此值得特别注意。

在深入探讨之前，重要的是要澄清，在今天的文章中，我们将重点关注PageSpeed，而不是页面速度。

对于不熟悉差异的用户，PageSpeed是Google的指标。 它基于一系列工具，当我们指的是0到100之间的PageSpeed数字时，我们指的是PageSpeed Insights工具的输出。

另一方面，页面速度通常是指网页的实际速度。 是的，有可能在不增加另一个的情况下增加一个，而且我什至看到在某些情况下改善一个是要牺牲另一个。

简而言之，我们将在本文中重点介绍与WordPress网站相关的Google指标。 每当您在进行操作时，也必须对另一项进行测量，以免使自己陷入脚下。

一个或另一个指标

虽然我会借鉴影响PageSpeed或Page Speed的经验，但是我的经验却是从我从未见过或参与过的场景中汲取的。 我将在撰写本文时进行这个小实验，以便提供屏幕截图和输出数字。

值得注意的是，在我撰写本文时，我不知道最终数字的结局。 我们正在争取80+达到“良好”水平，但这并不总是可能的。 我认为高于70的任何值都是合理的，因为随着时间的流逝，它会留出一些摆动的空间，并保持高于60阈值（我们降至“低”级）。

在本练习中，我无法提供具体的URL，并且在您阅读本文时，您不会看到起始编号，但是我想再次强调，我从未见过这种特定情况或以前如此低的水平。 在某些屏幕快照中，我将使用Search Engine Land作为占位符，但是此小实验正在另一个URL上运行。

我们从这里开始：

开始的分数是：

• 手机：57/100
• 桌面：0/100

是的，我已经连续数天检查了多次; 报告继续显示桌面得分为0！ 不好。 您的目标是获得最高分，以80分作为被评为“好”页面的起点。

我们还将查看页面加载的时间或页面的速度。 我还将这些数字也包含在改进指标之下。

重要的是要注意，每种工具的测量方法都不同。 我将以Dotcom-Tools.com为基础，但GTmetrix.com也能正常工作。

我使用Dotcom的原因是它在世界各地进行测试，而我给出的是平均值。

步骤1：HTTPS

第一步，用一块石头杀死两只鸟。 该站点具有由注册商提供和安装的安全证书。 他们做得很好，除了HTTP不重定向到HTTPS，并且Google缓存了HTTP版本。

第一步是使站点完全切换到HTTPS。 在我们的案例中，站点设置根本没有在“常规设置”中切换为HTTP。

将地址切换为HTTPS会创建301重定向，设置立即跳至：

• 手机：61/100
• 桌面：0/100

在开始之前，我们的页面速度为10.1秒。 为了让您大致了解我在上面提到的有关多个全球位置的信息，它从丹佛加载后仅需3.5秒。 切换到HTTPS后，页面速度提高到9.4秒。

如果站点没有自动重定向，则有一个名为Force HTTPS的插件来完成工作。 或者，如果您愿意，可以将以下内容添加到您的.htaccess文件中：

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteCond %{HTTP_HOST} ^(www\.)? domain \.com
RewriteRule ^(.*)$ https://www. domain .com/$1 [R,L]

您显然希望将代码从domain.com切换到您的URL。

步骤2：图片

曾经尝试过PageSpeed的任何人都会告诉您图像是导致页面减速的最常见原因。 就我们而言，我们看到了……

您没看错-超过15个不必要的MiB。

图像分为两类错误：

• 压缩和调整大小。 这意味着图像在物理上大于其所需的大小。 当图像添加到媒体库并以远远超过其占用尺寸所需的尺寸放置在页面上时，在WordPress中会经常发生这种情况。
• 压缩。 图像中有很多垃圾，对于网络而言，它们的质量通常可能比所需的质量高得多。 图像压缩可以解决这个问题。 提醒一下，如果您曾经使用过自动图像压缩系统，请尝试始终检查并确保图像以您想要的方式出现。 这种情况很少见，但是我遇到过质量明显下降的情况。

我通常使用我的图像编辑工具或Compressimage.toolur.com手动进行操作。 我将在本文中使用TinyPNG.com作为指标。

在将一张大图像从9.2MB减小到175 KB且对页面没有视觉影响后，仅通过优化图像，我们的得分就达到了：

• 手机：61/100
• 台式机：67/100

对于页面速度，我们现在的速度为5.5秒，或大约两倍。

对于PageSpeed，图像并不是移动设备上最大的问题，但它们很可能是台式机上最大的问题。 现在两个分数都在OK范围内。

步骤3：浏览器缓存

对于那些第一次进行此过程的用户，如果您将浏览器缓存视为问题，那么Google建议您告诉访问者其浏览器应保留特定资源多长时间。

例如，您可以向浏览器发送一条消息，指出可以将图像缓存两周。 这样，当访问者在两周内返回您的站点时，该站点的加载速度更快，因为许多资源只是从他们自己的计算机中提取的。

您可以设置大多数资源缓存的时间限制，范围从脚本和样式表到大多数图像类型。

设置浏览器缓存时，我倾向于使用两种方法：直接在.htacess文件中设置和通过插件W3 Total Cache设置。

直接在.htaccess文件中

设置浏览器缓存时，您可以在.htaccess文件中添加一些代码，但要提一个警告：如果不确定.htaccess文件是什么，最好采用下面概述的插件路由。

如果您决定上学并且使用.htaccess代码，则需要通过FTP来访问该站点，或者，如果您没有FTP访问权限，则可以安装插件WP File Manager，该文件授予对文件。

您将在.htaccess文件中添加以下内容：

## Start browser caching ##

有效期至
ExpiresByType图片/ jpg“访问1个月”
ExpiresByType图片/ jpeg“访问1个月”
ExpiresByType图片/ gif“访问1个月”
ExpiresByType image / png“访问1个月”
ExpiresByType text / css“访问1个月”
ExpiresByType text / html“访问1个月”
ExpiresByType应用程序/ pdf“访问1个月”
ExpiresByType text / x-javascript“访问1个月”
ExpiresByType应用程序/ x-shockwave-flash“访问1个月”
ExpiresByType图片/ x图标“访问1年”
过期默认为“访问1个月”

##结束浏览器缓存##

您可以根据需要调整访问时间范围。 如果需要在较短时间内刷新资源，则可以执行此操作。 例如，图像会定期更改但保留相同的文件名。

这是添加代码的方法：

导致：

• 手机：62/100
• 台式机：72/100

通过该插件进行的浏览器缓存为我们提供了5.1秒的真实速度。

通过W3总缓存

有一些缓存插件，最受欢迎的插件是W3 Total Cache和WP Super Cache。

我发现W3 Total Cache可以在大多数（但不是全部）情况下，在更大范围的任务中提供更好的结果。 尝试两者或两者来最大化您的结果从来没有什么坏处。

一旦安装了插件，启用浏览器缓存就和转到常规设置，勾选一个框并单击“保存所有设置”一样容易。

通过该插件启用浏览器缓存会产生相同的PageSpeed得分，并且实际页面速度也没有变化。

步骤4：减少服务器响应时间

通常，我们会遇到有人告诉我们减少服务器响应时间的情况。 您可能会担心需要升级托管环境，但这通常是不必要的。

减慢服务器速度的主要问题之一是PHP文件和数据库之间来回的混乱。 幸运的是，W3 Total Cache提供了页面缓存形式的解决方案。 实际上，即使您没有收到服务器响应警告，这也可以加快处理速度。

使用页面缓存，我们实质上是在创建页面的静态副本，而不是要求服务器在每次访问时都生成页面。 这会减轻服务器的负担。 在这里要解决的情况下，我们遇到了服务器响应问题，其中Google报告了0.6秒的响应时间，Dotcom Tools报告了573毫秒的首字节时间。

我打开了页面缓存：

突然我们到了：

• 手机：70/100
• 台式机：74/100

第一字节时间降至75毫秒。 值得注意的是，页面缓存设置中有此功能的自定义选项。 您可以选择在那里缓存和不缓存的页面等。

重要说明：请记住，您正在创建缓存的页面，这意味着它们不会更改。 更新页面时，W3 Total Cache被配置为清除该页面的缓存并重新构建。 但是，可以在不清除缓存的情况下更新菜单，小部件等更多全局更改。 如果您进行更改而看不到实时更新，只需单击插件区域中的任何“清除缓存”或“空缓存”按钮，即可进行设置。

步骤5：缩小

如果您曾经浏览过构成网页的文件，则将看到大多数文件包含多行和空白。 这些每个都将字节添加到文件。 删除这些字节称为最小化。

适用于WordPress网站的三种缩小类型为：

1. HTML。 实际页面本身的代码。
2. CSS。 样式表中的代码。
3. JavaScript。 您的各种脚本中的代码。

重要信息：每当您缩小文件（尤其是脚本）时，访问依赖于它们的网站页面以确保它们继续正常运行至关重要。

您可以使用的第一种方法是从Google自己下载缩小的文件：

它包括图像，但是有趣的是，我发现它没有像上面提到的方法那样出色。 您可以在此处下载JavaScript和CSS的简化版本，但是如果更新创建脚本的插件，则会弹出问题。 您将不得不重新做一遍。

同样，您可以使用CSSMinifier.com或JavaScript-minifer.com之类的工具。

请记住，如果插件更新以及该更新与脚本或样式有关，则必须在代码中排除调用原始文件的引用。 这可能很烦人。

另一种选择是再次返回W3 Total Cache，它包括常规设置中的功能（尽管您也需要在此处进入高级设置）。 您可以在以下位置找到它们：

我强烈建议一次缩小一次，并在每个之间进行测试。 如果发现问题，可以转到最小化设置并测试排除特定脚本和样式表：

如果发现页面导致特定页面（如联系页面或滑块）出现问题，也可以仅排除页面。 您能告诉我哪里找到最大的问题吗？

在大多数情况下，这是可行的，但偶尔，您会发现它无效（因为在我们当前正在研究的场景中没有，但这是一个很好的第一步）。 如果仍然不能改善问题，我建议使用插件Autoptimize完成相同的任务。

有了这个插件，我们的分数现在是：

• 手机：70/100
• 台式机：75/100

这是我们看到PageSpeed有所改善而实际站点速度没有改善的情况之一。

就是这样

您可能会发现，正如我们在此处遇到的那样，有些问题无法解决。 Google没有给我们100％的收益，这是为什么：

• 优化图像。 尽管我使用了上面的工具，但它们的大小还是小于Google自己提供的大小。 任何进一步的压缩都会导致图像质量下降。
• 在首屏内容中消除时钟计时JavaScript和CSS。 唯一剩下的问题是样式表，导致在应用样式之前，页面的呈现效果很差，持续了大约一秒钟。 我希望在给出的数字上要现实一些，除非我将速度保持在“差”类别，否则我不会在网站上移动它。 始终将用户放在引擎之前。
• 利用浏览器缓存。 我们利用了浏览器缓存，但是不幸的是，这仅适用于从我们自己的站点中提取的脚本。 我们无法利用浏览器缓存来获取外部脚本（例如来自Facebook或Google的脚本），例如此处的情况。

最终，我们在现实世界中的最终速度为3.0秒，在北美大部分地区都更好，最低速度为2.2。 为了进一步加快速度，我们需要研究清理WordPress代码，选择更快的主机和/或部署CDN。

但这是另一篇文章的另一个故事。

本文中表达的观点是来宾作者的观点，不一定是Search Engine Land。 工作人员作者在此处列出。