Thor Render Engine の紹介: 超高速ページの作成

私の名前は、Instapage のエンジニアリング担当シニア ディレクター、Piotr Dolistowski です。 ポーランドのワルシャワにある会社の技術部門を率いており、プロジェクトの調整や人員管理も含まれています。 今日の記事のすべては、Instapage の顧客向けに高速なページ レンダリング システムを作成するための私のチームの努力の直接的な結果です。

ページの読み込み速度がユーザー エンゲージメントと直帰率に直接影響することは、デジタル マーケターにとって周知の事実です。 Google やその他の企業は、少なくとも数年間、デジタル マーケティングに携わるすべての人にとってページの速度を重要視してきたため、2019 年にとって新しいことではありません。

これは以前から何度も紹介してきましたが、Google の調査によると、ページの読み込みが遅いとユーザー エンゲージメントが低下し、直帰率が上昇することが示されています。

これが、Thor Render Engine™ をお届けするために私たちのチームがたゆまぬ努力を重ねてきた理由です。 レンダリング エンジンは、新しいページ ジェネレーターであり、完全にレスポンシブなページ エクスペリエンスの一部であり、ユーザーの努力なしでクリック後のランディング ページが信じられないほど高速に読み込まれるようにします。

Instapage の新しいレンダリング システムの詳細に入る前に、クリック後のランディング ページの読み込みが遅いとコンバージョンに悪影響を与える理由を確認しましょう。

ページの読み込みが遅いことがコンバージョンに与える影響

ページの読み込みが遅いとはどのくらい遅いのでしょうか? モバイル ページの読み込み時間が 1 秒遅れるごとに、コンバージョンが低下します。

つまり、オンライン ユーザーは、ページが読み込まれるまで非常に長く待つことができません。 そのため、すぐに読み込まないと、ページを離れてしまいます。 これにより、直帰率が増加し、ユーザー エンゲージメントが低下し、全体的なユーザー エクスペリエンスが低下し、最終的にコンバージョンが制限されます。

Akamai は、トップのオンライン小売業者から 100 億回のユーザー アクセスに関するデータを収集した後、次のような洞察を得ました。

• 消費者の半分はスマートフォンで商品やサービスをブラウジングしますが、実際にモバイルで購入するのは 5 人に 1 人にすぎません。
• Web サイトの読み込み時間が 100 ミリ秒遅れると、コンバージョン率が 7% 低下する可能性があります
• Web ページの読み込み時間が 2 秒遅れると、直帰率が 103% 増加します
• モバイル サイトの訪問者の 53% は、読み込みに 3 秒以上かかるページから離れます
• 携帯電話の買い物客の直帰率が最も高く、タブレットの買い物客の直帰率が最も低かった

では、クリック後のランディング ページを高速に読み込むにはどうすればよいでしょうか? Google の PageSpeed Insights は役に立ちますが、どの程度でしょうか?

Google の PageSpeed Insights は、ページのパフォーマンスに関するレポートを作成し、モバイル デバイスとデスクトップ デバイスの両方でページが速いか、平均的か、遅いかを示します。 また、そのページを改善する方法についての提案も提供します。

ただし、技術的なバックグラウンドがない場合は、ページ速度の洞察に混乱する可能性があります. First Contentful Paint (FCP) と First Input Delay (FID) の指標が頭に浮かびます。

Instapage のThor Render Engine™ に入ります。

Thor Render Engine™ の詳細

当社は、すべての Instapage クリック後のランディング ページが高速に読み込まれるように、Thor Render Engine™ を開発しました。

これは、クリック後のランディング ページをあらゆる面で完全に書き直すことを意味し、HTML 構造、JavaScript と CSS のリファクタリング、CSS の応答性を変更して、ページのバックエンドにあるすべてのものを即座にロードできるようにしました。

これらすべての変更の最も優れた点は、Thor Render Engine™ が舞台裏で静かに動作してページを高速化するため、何もする必要がないことです。

ページの読み込みを高速化するために行った変更を詳しく見てみましょう。

HTML 構造

リソースの優先順位付けから始めて、HTML の観点からページ レンダリング システムを高速化するために多くのことが行われました。

リソースの優先順位付け

未使用、あいまい、または最適化されていない多くのコードのポスト クリック ランディング ページを取り除いた結果、明確で高速にレンダリングされるマークアップが作成されました。

新しい HTML 構造により、すべてのリソースが正しい順序で読み込まれることが保証されます。 ページ スタイル (フォント スタイルを除く) が head セクションに追加されました。これは、その後、CSS スタイルシートを使用するよりもページの読み込みが速くなるためです。

ページは高速に読み込まれ、コードを追加しなくても見栄えがよくなるため、応答性のために CSS や JavaScript にブレークポイントを追加する必要がなくなりました。 さらに、すべてのスクリプトはページ本体の下部に配置されるため、ページのレンダリングがブロックされることはありません。 重要なスクリプトとリソース (フォントなど) は、ブラウザーのプリロード機能を使用します。つまり、ページのレンダリング中にブロックされません。 また、ページの head タグには同期 JavaScript が配置されていません。

画像と動画の遅延読み込み

画像とビデオはレンダリングをブロックしませんが、ページに複数存在する場合、特に大きな画像の場合、リクエストが多すぎて帯域幅が詰まる可能性があります。 これは、トップ フォールド内の画像がフォールド下の画像と同時に読み込まれ、訪問者には表示されないため、ユーザー エクスペリエンスが低下する可能性があります。

この問題を解決するために、次の最適化を導入しました。

• スクロールせずに見える範囲の画像は優先度が高くなります— ダウンロードはすぐに開始されるため、ページがインタラクティブになる前でも表示されます。
• スクロールしなければ見えない位置にある画像と動画は遅延して読み込まれます。ユーザーがスクロールすると、ダウンロードがトリガーされます。 灰色のボックスは、まだ読み込まれていない画像のプレースホルダーとして使用されます。
• これらの灰色のボックスがユーザーに表示されないようにするために、ビューポートにスクロールするときに画像が実際に読み込まれます。 ただし、ビューポートの下部まで 400px の距離でスクロールすると。 それらがビューポートに入ると、それらはすでにロードされています。
• iframe に読み込まれる動画にも同じルールが適用されます。

これを実現するために、IntersectionObserver の最先端の API を活用しました。これにより、小さなコード サイズのフットプリントで遅延読み込みが非常に効率的になります。

JavaScript リファクタリング

JavaScript リファクタリングには、次の最適化が含まれていました。

1. モジュラー アーキテクチャ:クリック後のランディング ページのすべての JavaScript コードは、特定のウィジェットの機能に関連しています。 コードを複数のバンドルに分割し、それぞれに特定の機能のコードを含めます。 そのため、ユーザーが画像とリンクのみを含むページをデザインする場合、フォームまたはポップアップ ウィジェットのコードは読み込まれず、ページの読み込みが高速になります。
2. 超軽量:古いライブラリを削除し、コード アーキテクチャ全体を再設計しました。これにより、ページ上の JavaScript の合計サイズを 1 MB 以上から約 200 kB (つまり、5 分の 1 に減る!) に減らすことができました。上記のモジュール化のおかげです。
3. すべての非同期: JavaScript はレンダリングをブロックするため、すべてのスクリプトのインポートを BODY タグの末尾に移動しました。 これにより、ブラウザはスクリプトが実行される前にページ全体をレンダリングできるため、訪問者は意味のあるコンテンツをより早く見ることができます。 対話性を提供するスクリプトは、ページのそのセクションとの対話を開始した後でのみ、読み込まれて実行されます。 これにより、特にパフォーマンスが低く、インターネット接続がよくないモバイル デバイスで非常に優れたエクスペリエンスが提供されます。

CSS リファクタリング

また、CSS スタイルシート全体を書き直し、不要なサードパーティ コードを削除して、スタイルシートを再利用可能で読みやすく軽量にしました。 また、可能な限り CSS コードを再利用するために汎用 CSS クラスを使用しています。

また、GPU アクセラレーションを使用した CSS のみのアニメーションも実装しました。 CSS スタックの最も重要な変更は、ピクセルではなく相対単位「rem」を導入したことです。 このおかげで、クリック後のランディング ページは、スマートフォンから 4k デスクトップ ディスプレイまで、あらゆるデバイス サイズでスムーズにスケーリングされるようになりました。

CSS の応答性

「rem」を「vw」ユニットと組み合わせて使用​​して、クリック後のランディング ページをレスポンシブにします。 これは、クリック後のランディング ページが幅 768 ～ 1200 ピクセルと幅 400 ピクセル未満に縮小された場合、デバイスの解像度に 2 つのギャップがあることを意味します。 他のすべての解像度では、ビルダーと同様に、メイン コンテンツは固定幅のままです。 固定幅の値は、モバイルでは 400px、デスクトップでは 1200px です。

「レム」単位により、ウィジェットの位置とサイズをスムーズに再計算できます。 これは、これを実現するために JavaScript を使用する必要がないことも意味します。

要約すれば：

• 400px 未満のコンテンツは、画面の幅に合わせて自動的に拡大/縮小されます
• 400px から 767px の間で、コンテンツの幅は固定されています
• 768 ピクセルのモバイル ビューからデスクトップ ビューに切り替える
• 768px から 1200px のコンテンツは、画面の幅に合わせて自動的にスケーリングされます
• 1200px以上はコンテンツ固定

Thor Render Engine™ の速度テストの例

ポスト クリックのランディング ページ (デスクトップ、モバイル、タブレット) がどのように表示されるかわからないため、ページ エクスペリエンスが完全にレスポンシブであることが重要です。 Thor Render Engine™ ソリューションは、すべての解像度で完全に応答します。

新しいレンダリング エンジンと古いページ ジェネレーターを比較してみましょう。 以下の画像は、URL は異なりますが、同じページのページ速度の結果を示しています。 (注: これらの URL はテスト目的のみであるため、ページはアクティブではなくなりました):

古い Instapage ページのレンダリング結果:

Thor Render Engine™ の結果:

最初のテストで 56 点を獲得し、2 回目のテストでそれを 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 のデモにサインアップして、違いを体験してください。