うれしいことに、builder.ioのホームページは今やモバイル端末でもPageSpeed Insightsで100点中100点をとれるようになりました。 これはQwikを導入したおかげです。

Qwikはアプリケーションの規模に関係なく高いパフォーマンスを実現します。 上記のスコアは、以下の優れた技術によって達成されました。

• Qwikで提供されるページの起動に必要なJavaScriptは1KB未満
• ホームページは画面上の領域のコンテンツに必要なHTMLのみを送信
• Partytownを利用し、すべてのサードパーティスクリプトをWeb Workerに移動
• builder.ioの視覚的なノーコードエディタを利用してサイトを作成

Qwikは、数百のコンポーネントや数MBのコンテンツを有する大規模なサイトでも高速なパフォーマンスを実現します。 また、クライアントコンポーネントに移動できるインタラクティブなサーバーサイドコンポーネントも提供します。

過去のスコア

当社のストーリーはここから始まりました。

注目すべき点は、サイトのパフォーマンスが平均的であることです。 GoogleのPageSpeed Insightsは、モバイル端末において、ページの読み込みが開始されてから、ユーザーがリンクをクリックして反応が返ってくるまでの時間を7.6秒と推定していました。 これは優れたユーザー体験とは言えません。 さらに、GoogleはPageSpeed InsightsのスコアをSEOランキングに反映しています。

スコアがいまひとつである理由は、サイトの起動時に大量のJavaScriptを実行する必要があるためです。 現在は静的サイトでも、メニューやインタラクティブコンテンツに加え、Google Tag Manager、Intercom、CRMサービスといったサードパーティの解析スクリプトを追加するために、多くのJavaScriptを搭載しています。

JavaScriptサイトの速度を遅くする主な要因は、サイト自体とサードパーティスクリプトの2つです。

低速化の第1の原因はフレームワークです。 現代のフレームワークは優れた開発者体験を提供し、Webサイトのインタラクティブ性を高めます。 しかし、その代わりに大規模なJavaScriptをダウンロードする必要があるうえに、サーバーで生成されたHTMLと、フレームワークが予測するDOMを照合しなければならないため、起動時間が遅くなります。 このプロセスは差分検出や再ハイドレーションと呼ばれており、あらゆるフレームワーク（Qwikを除く）はこの宿命から逃れられません。 差分検出や再ハイドレーションで重要なのは、フレームワークがリスナーをDOMにアタッチし、サイトをインタラクティブにする部分です。 これが理由で、差分検出や再ハイドレーションは可能な限り早くしなければなりません。 そうしないと、サイトが機能しなくなります（メニューやチャットウィジェットがないサイトを想像してみてください）。

低速化の第2の原因はサードパーティスクリプトです。 確かに、現実にはPageSpeed Insightsのスコアが良いデモサイトや「新築」のWebサイトが数多くありますが、ほとんどの場合、スコアが良い理由はサードパーティスクリプトがまだ搭載されていないからです。 当社のサイトに搭載されているサードパーティスクリプトをいくつか紹介します。

• Google Tag Manager：現在のあらゆるサイトにとって必須の存在です。利用状況に関する統計データを収集し、サイトの使われ方や、どう改善すれば良いかについて、マーケティング上の知見を得るために利用されます。Google Tag Managerは最初に実行され、PageSpeed Insightsにおけるサイトの基準タイム以上のCPU処理時間を単独で消費するため、スコアが低下します。
• Intercom：顧客がサイトで開発者とリアルタイムでチャットし、質問をしたり、詳しい情報を聞いたりすることができます。
• Twitter：当社の製品に関する感想はTwitterウィジェットに表示されます。ウィジェットを利用するにはTwitterのJavaScriptを読み込む必要があります。

これらのスクリプトはすべて、サイトが読み込まれた時点で即座に実行され、上記の差分検出や再ハイドレーションのステップのためにCPUを奪い合うので、ユーザー体験が悪化します。

問題は開発者がこうした状況をほとんどコントロールできないことです。 マーケティングチームが必要とする解析機能やユーザーサービス機能を追加するには、サードパーティスクリプトを利用しなければなりません。 また、サイトの起動時に時間のかかる差分検出が求められる既存のフレームワークを利用する必要もあります。 開発者がコントロールできる部分は多くありません。 これが業界の現状であり、そのため標準的なアプローチでは誰もあまり良い結果を出せません。

QwikとPartytownは、この問題の解決を目指しています。

現在のスコア

この数値はモバイル端末のものです。 モバイル端末はデスクトップに比べて、優れたパフォーマンスを達成するためのハードルがはるかに高くなります。

上記の表は、当社が現在、QwikとPartytownでどれだけのスコアを達成したかを示しています。 これは非常に大きな改善と言えます。 Time to Interactiveは7.6秒から1.2秒へ、Total Blocking Timeは1.3秒から40ミリ秒へ短縮されています。 JavaScriptの実行時間を短縮できた直接の要因は、フレームワークについてはQwik、サードパーティスクリプトについてはPartytownです。

上記はQwikとPartytownを導入する前のパフォーマンスの解析結果です（モバイル端末のエミュレート）。

• ページの読み込みには1.8秒かかっています。
• メインスレッドは、ほとんどの時間、「差分検出」（DOMリスナーを設置する場所を探す作業）で非常にビジーな状態です。
• 上記の結果、多くのフレームが落ちています。
• メインスレッドが「差分検出」でビジーになる前に、JavaScriptコードを読み込むためのカスケードが生じています。

ここで、従来の起動時のパフォーマンスと、QwikとPartytownを導入した後のパフォーマンスを比較してみましょう。

• JavaScriptはダウンロードしていません。
• ページの読み込みにかかった時間は0.5秒です。
• メインスレッドは、ほぼアイドル状態です。
• フレームはほとんど落ちていません。
• Partytownの読み込みは後回しにされています。
• サードパーティスクリプトは（メインスレッドではなく）Web Workerで実行されています。

過去と現在のパフォーマンスには明らかな違いがあります。

重要なことは、QwikやPartytownのアルゴリズムが特別に優れているわけではないということです。 QwikやPartytownはほとんどのJavaScriptをメインスレッドから移動させて負担を軽減しており、それによってページを高速に読み込んでいます。 ただし、Qwikでは、たとえJavaScriptがほぼ存在しなくても、ページは完全にインタラクティブな状態に維持されます。 Qwikは「良いとこ取り」が可能なのです。JavaScriptのサイズを見てみましょう。

メインスレッドのJavaScriptを1.8MBから3.5KBに縮小できました。これは素晴らしい成果です。

元のサイトのJavaScriptは1.8MBで、うち219KBは開発者がコントロールできないサードパーティスクリプトでした。 つまり、サイト自体のJavaScriptは1.6MBで、そこには再ハイドレーションが必要なフレームワーク、テンプレート、スタイリングが含まれます。 標準的なフレームワークを利用する場合、サイトはコンテンツを2回ダウンロードすることになります。 1回目はHTMLとして、2回目はJavaScriptとしてのダウンロードです。 二重のダウンロードが1.6MBのコードの主な要因です（圧縮すると大幅に減って244KBになるため、サイトのテンプレートであると分かります）。

こちらを基準として、QwikとPartytownを利用した場合の3.5KBと比較してみましょう（圧縮すると2.5KB）。 再度強調しますが、QwikとPartytownを利用すれば、メインスレッドで実行する必要があるJavaScriptはわずか3.5KBになります。 メインスレッドの仕事がないので、サイトの読み込みはとても高速になります。 もう1つのポイントは、どんなにサイトが複雑化しても3.5KBのサイズは変わらず、いわば「固定費」であることです。

サードパーティコードの実行に関する問題はまだ残っていますが、これらのコードはメインスレッドより優先順位が低いWeb Workerのスレッドに再配置されています。 サードパーティコードは全体でも220KBで、メインスレッドのパフォーマンスに影響を及ぼさずに役割を果たすことができます。

さらに、もう1つポイントがあります。先ほど述べたとおり、既存のフレームワークはサイトを2回ダウンロードする必要があります。 1回目はHTMLとして、2回目はJavaScriptとしてのダウンロードで、JavaScriptのサイズは1.6MBです。 このような場合にQwikは威力を発揮します。 Qwikは1.6MBのJavaScriptを複数の異なるチャンクに分割します。 そして、Qwikはユーザーインタラクションがあったときだけ、JavaScript全体の一部だけをダウンロードします。 Qwikはコンポーネントを順不同に、かつ遅延して再ハイドレーションできます。 そのため、ユーザーがページ上で何らかのインタラクションをするまで、JavaScriptはまったく必要ありません。 さらに、ハイドレーションがコンポーネントごとに独立しているため、ユーザーのインタラクション時にJavaScriptのごく一部をダウンロード・実行するだけで、インタラクトされたコンポーネントのみをハイドレートできます。

つまり、メリットは以下の2つです。

1. ページの起動時に何もする必要がない。
2. 再ハイドレーションの必要があるときでも、範囲を限定し、（ページ全体ではなく）1つのコンポーネントだけを再ハイドレートできる。

最後に注目しておきたいのは、ページの大部分は静的なのでその部分のコンポーネントがハイドレートされることはなく、JavaScriptもまったくダウンロードされないという点です。

Qwikとは？

QwikはTime to Interactiveに焦点を当てた新しいタイプのWebフレームワークです。 Qwikには、サーバーで実行を開始し、HTMLへシリアライズし、クライアントに送信できるというResumability（再開性）があります。 クライアント側では、qwikloader.js（クライアント側で実行される1KB未満のJavaScript）がアイドル状態でユーザーのインタラクションを待っています。 ユーザーがインタラクトすると、Qwikはサーバーが処理を中断したところから実行を再開できます。 QwikにはResumabilityがあるので、起動時に差分検出をする必要がなく、ユーザーがインタラクトしたコンポーネントのみをハイドレートすればよいのです。 Qwikはサーバーでコンポーネントを作成し、それをクライアントへシームレスに移動できます。 これらすべてのプロセスによって、上記のとおり、アプリケーションは即座に利用可能になります。

画面外領域のコンテンツを遅延読み込み

QwikはすべてのステートをDOMに保持します。 これはQwik自体がステートレスであるという意味です。 ステートレス属性によって、画面外領域のコンテンツを遅延読み込みできます。

上記は既存のフレームワークではとても困難ですが、Qwikなら朝飯前です。

Partytownとは？

PartytownはサードパーティスクリプトをWeb Workerに再配置できます。 サードパーティスクリプトは、サイトのTime to Interactiveを遅くする最大の原因になっていることがよくあります。

次はどうなる？

私たちは、Qwikを皆さんに早く届けるために尽力しています。 Qwikによってどんなに素晴らしいサイトを開発できるか、皆さん自身の目で確かめてください。

シリーズ記事一覧