認識 Thor Render Engine™：Instapage 更快的頁面渲染系統

已發表: 2019-03-18

快速鏈接

頁面加載緩慢的影響
Thor Render Engine™ 背後的細節
HTML 重組
JavaScript 重構
CSS 重構
CSS 響應能力
速度測試示例
比較頁面速度
享受更快的頁面加載

我叫 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 重構包括以下優化：

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

CSS 重構

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

我們還使用 GPU 加速實現了純 CSS 動畫。我們 CSS 堆棧中最重要的變化是引入了相對單位“rem”而不是像素。多虧了這一點，點擊後登錄頁面現在可以在從智能手機到 4k 桌面顯示器的所有設備尺寸上平滑縮放。

CSS 響應能力

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

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

總之：