Core Web Vitals 不是您的问题?

如果您正在努力提高 Core Web Vitals 分数并且功亏一篑,那么您并不孤单。 轶事证据表明,实现高 Core Web Vitals 性能是困难的。 原因是出版商和 SEO 正试图修复技术上没有损坏的东西。

网站开发方式的范式转变

我们正处于网页创建方式的重大范式转变的开始阶段。 一个更快的网络主机是有帮助的,但它不会解决 Core Web Vitals 问题。

Core Web Vitals 是在以 3G 或 4G 速度在手机上浏览网页的移动设备下游计算的。 这就是 Core Web Vitals 数据的来源,如果下载因手机上的互联网连接不佳而受到限制,那么快速的 Web 服务器在那时几乎没有用处。

改进 Core Web Vitals 不是关于网络托管,而是更多关于修复代码。

修复没有损坏的东西

WP Rocket 最近使用 Gutenberg 重新设计了他们的网站。 考虑到古腾堡当时没有完整的网站编辑功能,这是一个勇敢且几乎是鲁莽的举动。

他们必须自定义 WordPress 处理 CSS 和 JavaScript 的方式,以提高 Google 页面体验分数。

换句话说,在重新设计他们的网站以在 Core Web Vitals 中获得高分时,WP Rocket 必须自定义 WordPress 本身,以使其成为它原本不应该成为的东西。

Core Web Vitals-不友好

Core Web Vitals 标准并不是 WordPress 开发人员在创建 WordPress 时所考虑的。 这就是为什么将推文嵌入到帖子中会触发累积布局转换的原因。

WordPress 和主题不为 Google 编码。 他们为出版商的需求编写代码,直到 2020 年 5 月才满足出版商的需求。

它也不仅仅是 WordPress。 大多数其他内容管理系统都没有内置 Core Web Vitals 最佳实践。

这并不意味着 WordPress 有问题。 WordPress 没有任何问题,因为 Google 说有问题。

Core Web Vitals 不是 WordPress 问题

Core Web Vitals 是一组由 Google 独立开发并推送到发布商和 SEO 社区以与之合作的指标。

WordPress与它无关。 Core Web Vitals 于 2020 年 5 月出现,显然没有与开发者生态系统进行任何协调或协商。

在 WordPress 方面,开发正在向前发展,就好像 Core Web Vitals 不存在一样。 而在发布者和 SEO 方面,WordPress 的用户承担着“修复” WordPress、Drupal、phpBB 等的任务。

在一个完美的世界中,创建一个满足用户需求的系统的工作在于开发人员方面。 但这并没有发生。

WordPress 甚至没有将 Core Web Vitals 视为 WordPress 问题。

当有人开始 WordPress论坛中的支持线程 他们被告知在谷歌的支持论坛中询问。

“你应该在谷歌论坛上提问,因为 WordPress 与此无关。”

出版商和 SEO 社区承担着合规性

WordPress 发布者一直在努力使网站符合这些网站从未设计为遵守的标准。

这就是为什么这么多人在 Core Web Vitals 上苦苦挣扎的原因。 出版商和 SEO 的负担是试图修复理想情况下应该在代码级别修复的问题。

提高 Core Web Vitals 分数就像试图将本田思域的性能升级到雪佛兰克尔维特的标准一样。

开发人员没有建造克尔维特。 他们建造了本田思域。

但谷歌要求司机(不是制造商) 将性能提高到 Corvette 级别。 你觉得这公平吗?

要求软件的用户而不是软件的开发人员来改进它是否合理?

Core Web Vitals 的软件合规性问题存在于代码级别,而不是用户级别。

那么,为什么出版商和 SEO 社区要承担修复他们只是用户的东西的负担呢?

谷歌有用吗?

Google 提供了许多用于诊断问题的工具,并提供了深入的文章来解释如何解决这些编码问题。

但这些是编码问题而不是用户问题。

开发社区与 Google 之间脱节的一个例子是累积布局移位的问题,当页面元素被下载时,网页会发生移位和重新排列。

Cumulative Layout Shift 的一个常见原因是图像没有声明高度和宽度大小。 谷歌推荐了一些奇特的解决方法,比如使用 CSS 来使用宽高比框来设置图像样式。

一般的出版商和 SEO 可能不会理解纵横比框是什么以及如何以不破坏网站的方式计算整个网站的比率。

看一看 在这和描述 谷歌链接的纵横比框,看看它是否对你有意义:

“完美的正方形和 16:9 的东西很棒,但用于这些的值只是简单的数学运算。 纵横比可以是任何东西,它们通常是完全任意的。 可以将视频或图像裁剪为任何大小。

那么我们如何计算上面 1127.34 × 591.44 SVG 的 padding-top 呢?

一种方法是使用 calc(),如下所示:

填充顶部:计算(591.44 / 1127.34 * 100%);”

天道酬勤!

这是另一个例子。 许多网页模板通常通过 CSS 将图像宽度设置为自动(宽度:自动;) 不设置图像的高度和宽度 为了使像徽标这样的图像按比例缩放以适应模板,无论它是在移动设备还是桌面设备上查看的。 这是导致累积布局移位的常见编码实践。

这就是 WP Rocket 必须深入研究并在整个站点范围内对 CSS 和 JavaScript 进行更改的原因。

例如,WordPress Gutenberg 会加载所有存在的 CSS,无论是否需要。 因此 WP Rocket 的开发人员不得不为此手动编写解决方案。

这就是 WP Rocket 解释他们在重新设计中所做的事情的方式:

“……我们弃用了几个未使用的块。 我们创建了一个自定义排队系统,仅在需要时才加载 CSS 和 JS 块。 我们只花了几分钟就开发了这个系统。

我们还决定不使用 Gutenberg CSS 文件。 相反,我们将我们实际需要的 CSS “迁移”到我们自己的样式表中,到一个专用的 CSS 文件中。 那成功了。”

重新思考网站的创建方式

了解 Core Web Vitals 问题很重要。 谷歌要求出版商和 SEO 使用 CMS 开发社区不感兴趣的解决方案。

以下是我们面临的各种妥协以及 Google 如何改变我们开发网站的方式的示例。

让我们谈谈字体。

渲染阻塞第三方资源会对最大内容绘制产生负面影响。 一个常见的瓶颈是从第三方网站(如 Google Fonts)下载字体。

有许多技巧可以应用,结合使用预加载链接属性和可能的​​一些 JavaScript 等,这使得下载第三方字体 Core Web Vitals 的过程变得友好。

但是,将那种花哨的字体抛在脑后会扼杀您的网站吗?

一个有助于提高得分的简单解决方案是将网站字体切换为 Apple、Windows 和 Android 设备已经在其系统中加载的无衬线字体。

切换到设备内置的有吸引力的字体意味着网站不再需要等待下载花哨的字体。

一种方法可能是这样的:

font-family: Helvetica, Tahoma, sans-serif;

如果 Android 没有在浏览器中加载 Helvetica 或 Tahoma,则设备将使用 Roboto 字体显示该站点。

Roboto 字体示例截图

对于习惯使用花哨字体的人来说,使用系统字体可能看起来很极端。 但这是网络出版商可能需要做出妥协的一个例子,尤其是处于竞争激烈的利基市场的出版商。

对于专注于页面速度和转换的附属网站来说,这种决定是显而易见的。

过渡的时刻

今天发生的事情是,我们生活在一个过渡的时刻。 事情正在从我们过去的做事方式转变为开发人员未来做事的方式(开箱即用)。

开发人员响应了对移动友好网站的需求。 随着时间的推移,他们可能会开始响应对 Core Web Vitals 得分较高的网站的需求。

CMS 系统、模板和插件的设计方式未能满足需要考虑 Core Web Vitals 的出版商的需求。

目前,技术 SEO 和开发者社区不得不“修复”没有损坏的东西,以使其符合谷歌关于网络应该是什么样子的想法。

当然,页面加载速度快且不会移动是一件好事。 但是要求软件的用户改进软件本身就是一种负担。

此时,修复代码的负担落在了 用户 的发布软件,而不是 开发商 那个软件。 感觉对吗?

可能发生的情况是,有些人可能会发现尽可能多地修复它很有用,其余的留到 WordPress 和其他 CMS 软件迎头赶上。

给TA打赏
共{{data.count}}人
人已打赏

这是现在如何建立链接:10 个数据支持的技巧

2021-11-24 13:17:56

WordPress 教程

如何将博客从 WordPress.Com 移动到 WordPress.Org

2022-11-10 2:49:14

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索