認識 Thor 渲染引擎：創建閃電般快速的頁面

我叫 Piotr Dolistowski，是 Instapage 的高級工程總監。 我領導公司在波蘭華沙的技術部門，包括項目協調和人員管理。 今天文章中的所有內容都是我的團隊為 Instapage 客戶創建更快的頁面呈現系統所做努力的直接結果。

頁面加載速度對用戶參與度和跳出率有直接影響，這對數字營銷人員來說已經不是什麼秘密了。 至少幾年來，谷歌和其他公司已經將頁面速度作為任何從事數字營銷工作的人的重點，因此這對 2019 年來說並不是什麼新鮮事。

我們之前已經多次介紹過這一點，但谷歌的研究表明，對於緩慢加載的頁面，用戶參與度會直線下降，而跳出率會上升：

這就是為什麼我們的團隊孜孜不倦地為您帶來 Thor Render Engine™。 渲染引擎是我們新的頁面生成器，也是我們完全響應式頁面體驗的一部分，可確保您的點擊後登錄頁面加載速度非常快，無需您付出任何努力。

在我們深入了解 Instapage 的新呈現系統的細節之前，讓我們回顧一下為什麼加載緩慢的點擊後登陸頁面不利於轉化。

頁面加載緩慢對轉化的影響

緩慢加載頁面到底有多慢？ 移動頁面加載時間的每一秒延遲都會導致轉化率下降：

翻譯：在線用戶沒有耐心等待您的頁面加載很長時間。 因此，如果它沒有立即加載，他們就會離開頁面。 這會增加跳出率，降低用戶參與度，不利於整體用戶體驗，並最終限制轉化。

Akamai 在收集頂級在線零售商的 100 億用戶訪問數據後得出以下見解：

• 一半的消費者在他們的智能手機上瀏覽產品和服務，而實際上只有五分之一的人在他們的手機上購買。
• 網站加載時間延遲 100 毫秒會使轉化率降低 7%
• 網頁加載時間延遲兩秒會使跳出率增加 103%
• 53% 的移動網站訪問者將離開加載時間超過三秒的頁面
• 手機購物者的跳出率最高，而平板電腦購物者的跳出率最低

那麼，如何才能確保您的點擊後登錄頁面加載速度快呢？ Google 的 PageSpeed Insights 可以提供幫助，但作用有多大？

Google 的 PageSpeed Insights 報告頁面的性能，顯示頁面在移動和桌面設備上是快速、平均還是慢速。 它還提供了有關如何改進該頁面的建議：

但是，如果您沒有技術背景，頁面速度見解可能會讓您感到困惑。 了解什麼是首次內容繪製 (FCP) 和首次輸入延遲 (FID) 指標可能讓您難以理解。

輸入 Instapage 的Thor Render Engine™。

Thor Render Engine™ 背後的細節

我們開發了 Thor Render Engine™ 以確保所有 Instapage 的點擊後登錄頁面都能快速加載。

這意味著要全面重寫點擊後登陸頁面的各個方面——更改 HTML 結構、JavaScript 和 CSS 重構以及 CSS 響應性，以確保頁面後端的所有內容都可以立即加載。

所有這些更改中最好的部分是您無需執行任何操作，因為 Thor Render Engine™ 在幕後靜默工作，使您的頁面快如閃電。

讓我們分解這些更改，看看我們為加快頁面加載速度所做的工作。

HTML結構

從 HTML 的角度來看，從資源優先級開始，很多工作都致力於使頁面呈現系統更快。

資源優先級

我們已經去除了大量未使用、模棱兩可或非最佳代碼的點擊後登錄頁面，從而產生清晰、快速呈現的標記。

新的 HTML 結構保證所有資源將以正確的順序加載。 頁面樣式（字體樣式除外）已添加到 head 部分，因為在那之後，頁面加載速度比使用 CSS 樣式表更快。

響應能力不再需要 CSS 或 JavaScript 中的額外斷點，因為無需額外代碼，頁面將加載快速且看起來很棒。 此外，所有腳本都放在頁面主體的底部，因此它們不會阻塞頁面呈現。 關鍵腳本和資源（例如字體）使用瀏覽器預加載功能，這意味著它們在頁面呈現時不會被阻止。 此外，頁面的 head 標記中沒有放置任何同步 JavaScript。

圖片和視頻延遲加載

儘管圖像和視頻不會渲染阻塞，但是當頁面上存在多個圖像和視頻時，帶寬可能會因請求過多而阻塞，尤其是對於大圖像。 這可能會導致糟糕的用戶體驗，因為頂部折疊中的圖像會與折疊下方的圖像同時加載，而訪問者看不到這些圖像。

為了解決這個問題，我們引入了以下優化：

• 折疊上方的圖像具有更高的優先級——下載立即開始，因此它們甚至在頁面交互之前就可見。
• 折疊下方的圖像和視頻是延遲加載的——當用戶滾動到它們時觸發下載。 灰色框用作尚未加載圖像的佔位符。
• 為了防止用戶看到這些灰色框，圖像實際上是在滾動到視口中時加載的。 但是當它們滾動到視口底部 400 像素的距離時。 當他們進入視口時，他們已經加載。
• 同樣的規則適用於在 iframe 中加載的視頻。

為了實現這一點，我們利用了 IntersectionObserver 的尖端 API，這使得延遲加載超級高效且代碼佔用空間小：

JavaScript 重構

JavaScript 重構包括以下優化：

1. 模塊化架構：點擊後登錄頁面上的所有 JavaScript 代碼都與特定小部件的功能相關。 我們將代碼分成多個包，每個包包含特定功能的代碼。 因此，當用戶設計一個只有圖像和鏈接的頁面時，不會加載 Form 或 Popup 小部件的代碼，從而使頁面加載速度更快。
2. 超輕量級：我們刪除了舊庫並重新設計了整個代碼架構，這使我們能夠將頁面上的 JavaScript 總大小從超過 1MB 減少到大約 200kB（減少了 5 倍！），而典型的頁面將加載不到 100kB由於上述模塊化。
3. 全部異步：由於 JavaScript 是渲染阻塞的，我們將所有腳本導入移到了 BODY 標籤的底部。 這允許瀏覽器在執行腳本之前呈現整個頁面，從而允許訪問者更早地看到有意義的內容。 提供交互性的腳本只有在它們開始與頁面的該部分交互後才會加載和執行。 這提供了非常好的體驗，尤其是在性能較低且互聯網連接通常較差的移動設備上。

CSS重構

我們還重新編寫了整個 CSS 樣式表，刪除了不必要的第三方代碼，使我們的樣式表可重用、可讀且輕量級。 此外，我們使用通用的 CSS 類來盡可能地重用 CSS 代碼。

我們還通過 GPU 加速實現了純 CSS 動畫。 我們 CSS 堆棧中最重要的變化是引入了相對單位“rem”而不是像素。 得益於此，點擊後登錄頁面現在可以在從智能手機到 4k 桌面顯示器的各種設備尺寸上順暢地縮放。

CSS 響應能力

我們將“rem”與“vw”單元結合使用，使點擊後著陸頁具有響應性。 這意味著當點擊後登錄頁面縮小到 768 到 1200 像素寬度和低於 400 像素寬度時，設備分辨率有兩個差距。 在所有其他分辨率中，主要內容保持固定寬度，就像在構建器中一樣。 移動設備的固定寬度值為 400px，桌面設備為 1200px。

“Rem”單位使我們能夠順利地重新計算小部件的位置和大小。 這也意味著我們不必使用 JavaScript 來實現這一點。

總之：

• 低於 400 像素的內容會自動縮放以適合屏幕寬度
• 在 400px 和 767px 之間，內容寬度是固定的
• 從 768px移動視圖切換到桌面視圖
• 從 768px 到 1200px 的內容會自動縮放以適應屏幕寬度
• 1200px以上內容固定

Thor Render Engine™ 速度測試示例

由於您永遠不知道人們如何查看您的點擊後登錄頁面（桌面、移動或平板電腦），因此頁面體驗完全響應非常重要。 Thor Render Engine™ 解決方案完全響應所有分辨率。

現在讓我們將新的呈現引擎與舊的頁面生成器進行比較。 下圖顯示了同一頁面的頁面速度結果，儘管 URL 不同。 （注意：這些頁面不再處於活動狀態，因為這些 URL 僅用於測試目的）：

舊的 Instapage 頁面渲染結果：

雷神渲染引擎™ 結果：

在第一次測試中獲得 56 分，在第二次測試中將其提高到 95 分，頁面加載速度提高了 58.9%！

頁面加載速度比較

在總結了 Thor Render Engine™ 的所有變化之後，讓我們看看 Instapage 的頁面加載速度與競爭對手相比如何。

我們在 3G 連接上測試了此頁面的速度（屏幕截圖僅顯示在首屏）：

這是頁面加載所需的時間：

• 使用舊的 Instapage 頁面呈現系統（頂行）：10.5 秒開始加載
• Thor Render Engine™（中排）：5 秒內，頁面加載 98%
• 使用競爭對手（底行）：8 秒開始加載

在 4G 連接上，結果如下：

• 使用舊的 Instapage 頁面渲染系統：4.5 秒開始加載
• Thor Render Engine™：在 3.5 秒內完全加載
• 使用競爭對手：4.5 秒才開始加載

使用 Thor Render Engine™ 享受更快的頁面加載

頁面速度在用戶體驗和最終轉化中起著重要作用。 當頁面加載時間滯後時，您不僅會冒高跳出率的風險，還會在此過程中造成沮喪的用戶。

借助 Thor Render Engine™，我們現在可以保證您的點擊後登錄頁面將立即加載，而無需您付出任何努力。 立即註冊 Instapage Enterprise 演示，親身體驗不同之處。