【まとめ】JavaScriptSEOオフィスアワー（2020年3月25日）

2020年3月25日のJavaScriptSEOオフィスアワーです。

JavaScriptSEOオフィスアワー

【Google翻訳】

JS開発者として、Webセキュリティのために持つべき/持たないべき5つのことは何ですか？

Martinは、クロスサイトスクリプティングとクロスサイトフォージェリのチェック、およびコンテンツセキュリティヘッダーの実装をお勧めします。これにより、多くの問題が防止されます。 コンテンツセキュリティポリシーを設定して、問題のある設定に関するフィードバックのみを報告してから、それらの設定をオフにします。 依存関係を更新し、最初は依存関係を減らし、5行で構築できる1つの機能のモジュールを含めないでください。

サードパーティのフォントがサイトのパフォーマンスに影響を与えないようにするための最良の方法は何ですか？

マーティンはサードパーティのフォントについてあまり気にしないことを推奨していますが、これらを自分でキャッシュして、何度もダウンロードしないようにすることができます。 フォントをサブセット化して、必要なフォントのみをダウンロードしていることを確認したり、システム/フォールバックフォントを使用してサイトをレンダリングしてから、新しいフォントを入れ替えたりすることもできます。 また、フォントファイルのウェイトを減らすことをお勧めします。この場合、独自のバージョンのフォントをインライン化またはホストすることを検討する価値があります。 ライセンス目的でこれを実行できない場合は、少なくともディスプレイスワッピングを使用してください。

JavaScript Webサイトの速度を最適化する際に従うべきベストプラクティスは何ですか？

可能な限り多くのJSを据え置き、可能であれば、最も重要なコンテンツをクライアント側のレンダリングに完全に依存しないでください。これは、ブラウザにHTMLを配信する速度が速ければ速いほど、JavaScriptに依存するほど遅くなるためです。特に、ランディングページと静的ページの場合はそうです。この場合、サーバー側レンダリングまたはハイドレーションでのサーバー側レンダリングを検討する必要があります。

新しいプロジェクトを開始する場合は、next.js、nuxt.js、Angular Universalなどの高レベルのフレームワークを検討する価値があります。本当にクライアント側のレンダリングにこだわる必要がある場合は、少なくとも依存関係を基本的にツリーシェークしてJavaScriptをできるだけ高速にして、依存関係に絶対に不可欠で必要なコードだけを残してください。

できるだけ多くのコードをバンドルすることを検討してください。また、コードをパッケージに沿って分割して、意味のあるものにしてください。たとえば、アプリケーションにすべてのバンドルが必要な場合があります。ブラウザをバックグラウンドで実行するので、それらを分割して他のバンドルをプリフェッチして、より高速にすることができます。

一般的な経験則として、JavaScriptが少ないほど、出荷量が多くなります。

フォントなどのキャッシュアセットについては、サービスワーカーを使用することをお勧めしますか？

要するに、はい、いいえ。 はい、一般的に、特にレイテンシを削減するという意味で、Service Workerを使用してネットワークアクティビティを削減することがすばらしいユーザーにとっては、常にネットワークからローカルキャッシュからフェッチするためです。

ただし、検索エンジンは積極的かつ積極的にキャッシングを行うため、Googleは長期間のキャッシングとフィンガープリント、またはアセットのある種のバージョン管理を使用することをお勧めします。 これについての詳細は、web.devの最初の防衛線であるキャッシュを読むことをお勧めします。

クロールの第二の波のようなものはありません

セカンドウェーブクロールは過度に単純化されており、Googleに時々興味深い影響を与えています。

基本的に、サイトマップは、Googleが他の方法では見つけることができないものをすばやく発見するのに役立ちます。 異なるページ間で非常に適切にリンクされた構造がある場合、サイトマップはクロール速度を向上させることはできませんが、サイトマップがあれば、間違いなく新しいコンテンツをすばやく見つけることができます。

サイトマップは、Googleがコンテンツを利用し、サイト上のリンクを発見するための実際の別の方法です。

リソースファイルをフィンガープリントする場合、名前を変更する方が良いですか、それともパラメータは機能しますか？

ここではパラメータが正常に機能します。 ただし、設定によっては注意が必要な場合があります。 たとえば、中間にキャッシュがあるか、クエリパラメータを何らかの方法で強制終了するリバースプロキシがある場合、一部のCDNが持つ傾向があるため、これは機能せず、デバッグが困難になることがあります。 これは、複数のホストおよびインフラストラクチャの一部全体で問題のトラブルシューティングを行うために必要なレベルのロギングがない可能性があるためです。

マーティンは、一般的にはそれほど大きな違いはないが、ファイル名に含めることは、異なる環境全体でおそらく少し堅牢であることを通知しましたが、一般的に言えば、パラメータを使用することは問題ありません。

一般的に言えば、レンダリングJavaScriptが大幅に速くなった

Googleは最初のHTMLで分析を実行しており、特にリンクを発見しています（サーバー側でレンダリングした場合は、リンクの発見が最速です）。 しかし基本的には、すべてのページがレンダリングされると想定できます。 最初のクロールから中央値としてのレンダリングまでの間に、キューに5秒の遅延があり、さらにページのレンダリングに実際にかかる時間があると想定できます。

ページが長すぎる場合、レンダリングプロセスは停止しますか？

マーティンは一般的にグーグルがこれを行うと説明しましたが、それは多くのヒューリスティックスとシグナルに依存しているので、どの時点で明確に言うことは非常に困難です。 彼はそれについてあまり心配しないことを勧めます。 ユーザーにとって高速であれば、問題はないはずです。 しかし、たとえば、ユーザーが実際にコンテンツを取得するために2分間バインドする必要がある場合、問題が発生する可能性があります。 ただし、これはSEO固有の問題ではないため、SEOの場合はこれについて心配する必要はありません。

ローカルにルーティングしているSPAに404コードを表示することをどのように推奨しますか？

通常、404ステータスコードを表示するには2つのオプションがあります。ページのインデックスを作成しないか、実際の404ページにリダイレクトできます。 これらは両方とも、互いに優れたソリューションです。 ただし、マーティンは、Googleは最初のHTMLしか表示せずに停止するため、レンダリングされたページにロボットのインデックスがないことは表示されないことを通知しました。 マーティンは、これらのソリューションが正しく実装されていることを確認することをお勧めします。そうでない場合、両方とも問題を引き起こす可能性があります。

SEOコンサルタントのまとめ

技術者の方に参考にして頂ければと思います。