ゲーミンググーグル — パーフェクトなライトハウススコア

私はいつも自分のコードを共有するのをためらっていました。標準以下だと思っているわけでも、インポスター症候群に悩まされているわけでもありません。コードを共有することで、私の心の狂気を垣間見ることができ、それが他の誰にとってもどういうわけか残酷に感じられるというだけです。私を正気の瀬戸際に追いやった旅を案内させてください。すべてはグーグルのライトハウスのアップデートから始まりました。

SEO初心者にとって、GoogleのLighthouseのアップデートは、ウェブサイトのパフォーマンスとベストプラクティスの順守にかかって、検索ランキングに大きな変化をもたらしました。ウェブサイトをテストしたい場合は、デスクトップの Chrome で開き、F12 キーを押して Chrome デベロッパーツールを開き、[ライトハウス] タブをクリックします。[デスクトップ] または [モバイル] を選択し、[分析] をクリックします。約 1 分後に、パフォーマンス、アクセシビリティ、ベストプラクティス、SEO、プログレッシブウェブアプリ (PWA) について、それぞれ 0 ～ 100 の範囲の 5 つのスコアが表示されます。

技術的な詳細を掘り下げる前に、自己紹介をさせてください。私の名前はジョナサン・グランサムです。ERPとITSMソフトウェアを専門とする小さなB2B SaaS企業、Nexoidのオーナーであることを誇りに思っています。この記事で取り上げているウェブサイトは www.nexoid.com. 気軽に見て、ソースコードを開いてください。LinkedInで私をフォローすることもできます。私のプロフィールは www.linkedin.com/in/jonathongrantham/

Google Chrome Lighthouseのアップデートがリリースされたとき、私は良心的なビジネスオーナーなら誰でもするであろうことをしました。自分のウェブサイトをチェックしたのです。残念なことに、結果は満足のいくものとはほど遠いものでした。パフォーマンスのスコアが21/100、アクセシビリティが30/100、ベストプラクティスが45/100、SEOが11/100、PWAの失敗というスコアで、私はショックを受けました。私は個人的に React.js を使ってかなり標準的なシングルページアーキテクチャの Web サイトを構築しました。スコアは壊滅的な打撃でした。

最初の挫折に惑わされることなく、私はMS Codeを立ち上げ、パフォーマンスを第一の目標として、問題に1つずつ対処し始めました。Lighthouse ツールに用意されているガイドは非常に役に立ちました。JPEG と PNG のすべての画像を最新の WebP ファイルに変換し、すべての img タグに幅と長さのプロパティを設定してレイアウトがずれないようにしました。これらの修正だけでスコアが 21/100 から 60/100 に上がりました。これは大幅な改善でしたが、完璧にはほど遠いものでした。残された唯一の提案は「未使用の JavaScript を減らす」ことでしたが、これは特に役に立ちませんでした。存在する JavaScript は React.js フレームワークだけで、それ以外はすべて排除されていました。

Nexoidの導入により、AM Digitalは統合ITSMソリューションのメリットを顧客対応業務にも広げることができました。Azure と統合されたクライアントポータルは、よりつながりのあるダイナミックでシームレスなエクスペリエンスを顧客に提供し、その結果、顧客の満足度とエンゲージメントが向上しました。このポータルでは、クライアントのデータとリアルタイムで同期できるようになり、すべての情報が最新かつ正確であることが保証されたため、サービスの提供が強化され、クライアントと企業の関係が強化されました。

この問題を解決しようと粘り強く努力したにもかかわらず、私は絶え間ない障害に直面していました。React.js の一部を削除したり、「遅延読み込み」を試したり、さまざまなオプティマイザーや圧縮をテストしたりしました。しかし、この問題はサイズが約 0.5 MB の React.js 自体に起因していました。

ベテランのウェブ開発者がこう叫ぶのがほとんど聞こえます。「ウェブサイトにReactを使わないでください！Web アプリケーションを構築するためのものです！」このことは今となってはよく知っています。

最初は数枚の画像を変換するという一見単純な作業でしたが、今では新しいフレームワークを使用した完全なウェブサイトのオーバーホールへと変わりました。イライラして、息を切らしながらいくつかの選択語を発した私は、適切な代替品を探しに出かけました。最初は Vue を検討し、後には Angular を検討しました。これらは間違いなく React.js の最大の競合相手です。しかし、どちらも同じ問題を抱えていました。

物事を単純化するために、私は古い技術を調べることに決め、jQueryを試してみました。しかし、私は同じ問題に直面しました。Googleの神々をなだめるような、既製のシングル・ページ・アーキテクチャ・フレームワークがないことがはっきりとわかりました。

残っている唯一の選択肢は、バニラJavaScriptに頼ることだったようです。

私の一連の実験は、JavaScriptを使わない基本的なHTMLページから始まりました。次に、内容を置換できる div を含む HTML ページを試してみました。JavaScript を使用してページに複数の変更を同時に加えると、Lighthouse からペナルティが科せられることにすぐに気付きました。解決策は、body タグの内容を文字列として操作してから再統合することで、目に見える DOM の変更を 1 つだけ作成することでした。

これで、bodyタグが空になり、headタグに小さなonload関数が追加されたミニマルなHTMLページができました。この関数は URL を検査して HTML GET リクエストを実行して、ページの本文 HTML を含む対応するテキストファイルを取得しました。これは適切な解決策だと思う人もいるでしょう。残念ながら、JavaScript の機能を動的に読み込もうとしたらうまくいきませんでした。

他のタグとは異なり、本文の内容文字列に単純な警告 (「yes this fired」) を付けたスクリプトタグを追加しても実行されません。理想的とは言えませんが、回避策の 1 つは、本文の文字列を解析し、スクリプトタグの内容をすべて特定して、それを JavaScript の評価関数に入れることでした。この方法はある程度効果的でしたが、名前空間を扱うときにつまずき、開発者コンソールには見苦しい警告が殺到しました。解決策は、HTML からスクリプトタグを抽出し、DOM がレンダリングされた後にスクリプト要素として追加することでした。Google は何らかの理由でこの行為にペナルティを課しませんでした。

進歩は進んでいて、基本的なシングルページアーキテクチャのソリューションができました。しかし、それほど速くはありません。Google ではシングルページアーキテクチャページのインデックス作成が効率的ですが（ブラウザで開き、すべての JavaScript を実行して DOM をスキャンします）、Bing、Yahoo、その他の主要な検索エンジンも同様のシンプルな方法を採用しています。ただし、Facebook、Reddit、LinkedIn、WhatsApp などの他のほとんどのプラットフォームは、HTML ファイルのみを取得し、本文が空白の小さな HTML ファイルを取得します。私のソリューションは実行不可能でした。今では、このコンセプトを Web サイト上のすべてのページに適用し、ユーザーがリンクをクリックしたときにシングルページアーキテクチャモードに切り替えるように JavaScript を組み込む必要がありました。

私のソリューションに基づいて、各ページのHTMLを生成できるツールが必要でした。そこで思い浮かんだのが、自分専用のERPシステム、Nexoidという完璧なリソースでした。ウェブサイトとウェブページのデータオブジェクトを含む Nexoid モデルを作成しました。ウェブサイトレコードは汎用テンプレートウェブページの作成を容易にし、ウェブページレコードには個々のページのコンテンツが含まれていました。パズルの最後のピースは、Web サイトレコードと関連するすべての Web ページレコードを読み取って HTML ファイルを生成できるワークフロー関数またはスクリプトでした。数日後、運用可能になりました。基本的なコンテンツ管理システム (CMS) を作成しました。ここまでの CMS の開発はそれほど複雑ではありません。他の CMS ワークフロー、承認、ローカリゼーション、プレビューなどを統合する際に本当の課題が生じます。

新しいウェブサイトの重要な要件はローカリゼーションでした。私たちはそれを11言語で立ち上げることを目指しました。IT 企業である私は、当然ながら技術的なソリューションに傾倒していました。ページごとに翻訳者を雇うのではなく、AWS Translate を選びました。AI 翻訳者はまともですが、完璧ではありません。エラーが目立つので、人間以外の出所が明らかになるほどです。フランス語を話すスタッフがAI翻訳を評価し、「理解できるが、適切なフランス語ではない」と説明して6/10と評価しました。

しかし、私たちは貴重なトリックに出くわしました。最初にChatGPTを通して英語のテキストを入力し、「これを整理して」と頼み、それを貼り付けると、英語のままで言語モデルとの互換性がはるかに高い方法でテキストが書き換えられることがわかりました。ChatGPT の書き換えられた英語を翻訳のベースとして使用すると、翻訳品質が大幅に向上し、10 点満点中の 9 点や 10 点まで上がります。

ウェブサイトを作成するための強固な技術基盤を構築したことで、私は進歩を遂げていました。しかし、より複雑なページを作成し始めると、新たな課題が浮上しました。ライトハウスの新しいガイドラインでは、すべての JavaScript、CSS、HTML を 1 つのファイルに統合することが必要になりました。これはシングルページアーキテクチャバージョンにも当てはまりました。

すべてのJavaScriptファイルとCSSファイルをインラインタグとして挿入することにしました。シングルページアーキテクチャバージョンでも同様の戦略が必要でした。すべてのスクリプト、スタイル、HTML を含む JSON ファイルを作成しました。

Lighthouse は次の問題をアセットのサイズだと判断しました。HTML と JSON のページファイルが大きすぎたのです。この問題は、HTML、CSS、および JavaScript ファイルを圧縮するように特別に設計された Node.js ライブラリ「minify」を使用して解決しました。このソリューションにより、テキストファイルのサイズを 40% 以上削減できました。さらに、minify には難読化という利点もあり、未加工のコードが読みにくくなり、セキュリティが強化されました。

ホスティングのトピックについて詳しく見ていきましょう。従来、コンテンツ管理システム (CMS) は、ユーザーの HTML リクエストを処理するアプリケーションサーバーを介して動作します。URL からのページリクエストを解釈し、データベース内の対応するアセットを見つけ、データベースレコードを (他のレコードと一緒に) 取得し、情報を処理してページを組み立て、最終的にフラットな HTML ドキュメントとしてエンドユーザーに配信します。この説明は主に、ユーザーが新しい Web サイトにアクセスしたときの最初の HTML リクエストに関するものですが、私は AJAX やその他の類似技術については知っています。

ただし、この従来のモデルには、新しいライトハウスの世界ではいくつかの欠点があります。まず、アプリケーションサーバーとデータベースサーバー間の相互通信とページのコンパイルに遅延が生じます。2 つ目は、最も単純な形式では、アプリケーションサーバーとデータベースサーバーは物理的に 1 つの場所でしか使用できません。このセットアップは、同じ建物や都市にいる場合は優れていますが、地球の反対側からサイトにアクセスしようとすると効率が大幅に低下します。たとえば、オーストラリアと英国間の ping の平均待ち時間は約 250 ミリ秒です。

これらの課題に対する当社のソリューションは、前述のパブリッシュスクリプトによって生成された静的ファイルをホストするために AWS S3 を使用し、グローバルなコンテンツ配信に AWS CloudFront を利用することです。この記事を書いている時点では、AWS CloudFront は 47 か国の 90 以上の都市にコンテンツを配信していました。オーストラリアのメルボルン在住者が英国のウェブサイトにアクセスする場合、AWS CloudFront は ping レイテンシーを 250 ミリ秒からわずか 13 ミリ秒に短縮しました (これは、メルボルンとシドニーの AWS エッジサーバーとの時差です)。

ここで、Lighthouse テストのプログレッシブ Web アプリケーション (PWA) コンポーネントにたどり着きました。これは、これまであまり検討していなかったことです。なじみのない方のために説明すると、PWA には Web サイトを Web アプリケーションとして管理する JavaScript サービスワーカーが関与します。少し複雑な場合は、このように考えてみてください。本質的には自動ダウンロードとキャッシュを行うツールです。ユーザーがウェブサイトにアクセスしたときの目標は、それ以降のリクエストをできる限り迅速かつシームレスに行うことです。PWA Service Worker を使用すると、次のアセットをユーザーのローカルマシンに既にダウンロードしておくことができるため、インターネット GET リクエストをもう一度行う必要がなくなります。

この記事を書いている時点では、Nexoid Webサイトは比較的小さく、19ページしかありません。ただし、この 19 ページは 11 の異なる言語に翻訳され、合計 209 ページになります。最初は、すべてのアセットをサービスワーカーにダウンロードしようとしましたが、その量は約 5 MB でした。このサイズは初期ロードには大きすぎたため、Lighthouseは私にペナルティを課しました。各ページの表示に必要な CSS、HTML、JavaScript がすべて含まれている英語ページ JSON ファイルのみをダウンロードすることにしました。

最終的な構造は次のとおりです。S3 バケットには、.html 拡張子を付けずに名前が付けられたコンパイル済み HTML ファイルが格納されます。たとえば、www.nexoid.com/en は英語のホームページ HTML を表し、www.nexoid.com/de はドイツのホームページ HTML を表し、www.nexoid.com/en/platform は英語のプラットフォーム HTML を表す、というようになります。さらに、https://www.nexoid.com/en.json、https://www.nexoid.com/de.json、https://www.nexoid.com/en/platform.json など、ページ間を移動する際に変化する体と頭の部分を含む JSON ファイルもあります。

結論として、ライトハウスを理解することは大きな課題でした。従来の標準的な CMS 製品がこの課題に効果的に対処できるかどうかは、私には懐疑的です。WordPressやDrupalのようなプラットフォームでの私の経験を振り返ると、これらを最適化してLighthouseの完璧なスコアを達成できるとは信じがたいです。全体的に見て、この努力は報われるものだと思いますし、Googleがパフォーマンスにもっと重点を置くのはもっともなことです。しかし、この変化はウェブデザイナーやエージェンシーにとって大きな問題であり、今後もそうであり続けるでしょう。

Lighthouseについてもっと知りたい方、またはNexoidの製品やサービスについてお話したい方は、遠慮なくご連絡ください。LinkedIn または当社ウェブサイトの「お問い合わせ」ページからお問い合わせいただけます。