聊天小部件 100% pagespeed

Arjen Karel - linkedin

Last update: 2024-11-27

简而言之

在本文中，我将向您展示如何在不牺牲页面速度和 lighthouse 分数的情况下添加聊天小部件。

大多数聊天小部件不考虑您的页面速度。它们加载多个 iFrames、样式表和 JavaScript 文件。您无法控制内容或加载机制。最好的情况是它会让您的页面响应速度变慢，最坏的情况是它会影响重要指标，如 Largest Contentful Paint。

这就是为什么我们在添加聊天小部件时必须即使，以便您的访问者尽可能少地感到不便，并且您的页面最重要的内容尽可能快地呈现。

聊天小部件是如何工作的？

聊天小部件通常以某种 JavaScript 代码的形式出现。将此代码添加到网页的 HTML 中。无需自己进行任何编码，您将自动看到聊天小部件出现在您的页面上。

创建聊天小部件的 JavaScript 通过在您的页面上放置 1、2 甚至 3 个 iframe 来实现这一点。iframe 是嵌入在您页面中的迷你网页。聊天不在您的站点上运行，而是通过聊天插件本身的站点运行。在 iframe 和处理整个聊天的聊天服务器之间建立连接。

聊天小部件对 lighthouse 分数的影响

加载聊天 iframe 通常是一件相对昂贵的事情。必须在您的页面内加载新的聊天页面。此聊天页面通常需要大量 javascript，这需要时间来加载和执行。总而言之，这对您的 lighthouse 分数有重大影响。例如：我们的 lighthouse 分数下降了不少于 35 分：

Speed index +3.6sec
Time to interactive +10.9sec.
Total blocking time +1 sec.

如何通过聊天小部件提高 lighthouse 分数

许多网站管理员认为聊天小部件只会减慢页面速度，对此无能为力，因为他们对聊天小部件几乎没有控制权。他们部分是对的。您必须粘贴到站点中的 javascript 片段不会直接通过延迟。JavaScript 在您的页面上启动一系列操作。这些操作会减慢网页速度，确实：您对此几乎没有影响力。

这就是为什么我们必须即使并绕过这个问题。没有替代方案。我们需要确保聊天小部件不会阻碍页面的呈现。聊天小部件应在浏览器的 'main thread' 完成加载和呈现页面后执行。

我们通过使用 JavaScript 函数 setTimeout() 和页面加载事件来实现这一点。当 HTML、CSS 和 JavaSript 加载并解析时，会触发加载事件。 setTimeout() 函数在给定的毫秒数后执行给定的命令。此示例：setTimeout(function(){alert('test')},4000)将在 4 秒（或 4000 毫秒）后在您的浏览器中弹出警报。

我们可以使用加载事件和 setTimeout 函数将聊天小部件的呈现延迟到 HTML、CSS 和 JacvaScript 解析后 1500 毫秒。此时我们非常确定浏览器的 main thread 处于空闲状态。

. 首先，我们要将聊天小部件包裹在一个函数周围。然后在加载事件后 1500 毫秒调用此函数，此时 main thread 最有可能处于空闲状态。当我们在本页面上为 facebook 聊天插件实现此功能时，您最终将获得此代码

var _x = function(d, s, id) {
    window.fbAsyncInit = function() {
        FB.init({
            xfbml: true,
            version: 'v8.0'
        });
    };
    var js, fjs = d.getElementsByTagName (s) [0];
    if (d.getElementById(id)) return;
    js = d.createElement(s);
    js.id = id;
    js.src = 'https://connect.facebook.net/en_US/sdk/xfbml.customerchat.js';
    fjs.parentNode.insertBefore (js, fjs);
};

setTimeout(function() { _x(document, 'script', 'facebook-jssdk') }, 4000);

您可以对任何聊天插件执行此技巧。它需要一些手动工作，例如您不能使用 WordPress 插件。搞不清楚？我很乐意为您提供帮助！

我们现在解决了所有 page speed 问题吗？

当聊天小部件通过上述方式加载时，我们的聊天小部件获得了 100% Lighthouse 分数。这是否意味着我们解决了所有 page speed 问题？

是的，部分解决了，但不是全部。我们使用渐进式呈现来尽早加载页面最重要的部分，同时将不太重要的部分（聊天小部件）推送到加载周期的末尾。重要指标如 LCP (Largest Contentful Paint) 和 FCP (First Contentful Paint) 显着提高，因为我们可以从 '关键呈现路径' 中移除了聊天小部件。这允许浏览器更早地离开 '阻塞模式'，从而大大降低了初始阻塞时间。

在那之后，这就变成了另一个故事。通过将聊天小部件推送到页面加载周期的末尾，它不在 lighthouse 测量范围内。一旦聊天小部件开始加载，浏览器的 main thread 将被阻塞。页面暂时不再具有交互性。此行为的影响取决于聊天小部件。大多数流行的聊天小部件在稍后执行时不会明显阻塞页面。

聊天小部件的构建方式使得它们在设计上会导致 pagespeed 延迟。为了加快页面速度，我们需要做出选择。这些选择从来都不是完美的。将聊天小部件推迟到加载周期末尾将导致更早的 LCP 和 FCP，另一方面，一些速度增益尚有解释空间。