Moz - SEOとインバウンドマーケティングの実践情報

ページを1秒以内に表示するための最新技術、そしてSEOの未来（テクニカルSEOの復権最終回）

「ページ表示速度」、そして「SEOはどこに向かっているのか？」「SEOに再び偉大なものに ―― Let's Make SEO Great Again」

Moz 2017/2/20 7:00 SEO | 解説／ノウハウ

「SEOにテクニカルな要素はもうない」というのは本当だろうか？今の時代に改めて重要性が増しているテクニカルSEOを解説するこの記事、全6回の最終回は、ページの読み込み速度について考察し、SEOの今後の展望についても考えてみよう。

まず前回までを読んでおく
→第1回「ウェブ技術の進化」「JavaScript」「HTTP/2」
→第2回「SEOツール」「検索順位」「クローキング」
→第3回「クロール」「スクレイピング」
→第4回「コンテンツとリンク」
→第5回「リダイレクト」「構造化データ」

グーグルは今もページの表示スピードにこだわっている

グーグルは、特にモバイル環境において、ページスピードを巡り非常に思い切った見方をしている。具体的には、次のように考えているのだ。

スクロールせずに見える範囲のコンテンツは、1秒以内で読み込まれるようにするべきだ。

しかし、そのうち600ミリ秒については、我々には手の打ちようがほとんどない。

画像：グーグル

SEO担当者として直接手を出せるのは、コンテンツを画面に表示させる200ミリ秒だ。読み込みスピードを改善するためにページ上で打てる手は、クリティカルレンダリングパスのためのページ最適化が大部分を占める。

画像：Nianpeng Li

クリティカルレンダリングパスの考え方を理解するには、まずブラウザがウェブページをどのようにして表示するのかをおさらいしておこう。

ブラウザはアドレスバーで指定されたURLを受け取り、そのドメイン名についてDNSルックアップを実行してIPアドレスを調べる。
ソケットが開き、相手サーバーとの接続のネゴシエーションが完了したら、要求されたページのHTMLをサーバーに求める。
ブラウザはHTMLを解析してドキュメントオブジェクトモデル（DOM）を生成し、CSSがあれば、CSSを解析してCSSオブジェクトモデル（CSSOM）を生成する。
その過程でJavaScriptがあると、そのJavaScriptが非同期のものでなければ、JavaScriptの実行の完了までDOMやCSSOMの生成をいったん停止（保留）する。
これがすべて完了するとブラウザはレンダーツリーを作る。それからページのレイアウトを構築し、最後にページの要素を画面に描画する。

Chromeのデベロッパーツールのタイムライン（Timeline）を見ると、個々の動作がどのように展開していき、読み込み時間にどう関係しているのかがわかる。

タイムラインの上部のグラフ部分は黄色が大部分を占めるだろう。これはページ構築のどの段階でもJavaScriptの実行が最も時間を食うからだ。JavaScriptのせいで、スクリプトの実行が完了するまでページ構築が停止する。これは「レンダリングをブロックしている」JavaScriptと呼ばれる。

この言葉にはなじみがあるかもしれない。それは、どう改善すればよいのか答えを求めて「PageSpeed Insights」を見て回っていると、次のような文言をよく目にするからだ。

修正が必要：
スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する

PageSpeed Insightsは、もともとクリティカルレンダリングパスの最適化を支援するために作られており、リソースの静的なサイズ変更、非同期スクリプトの利用、画像の大きさの指定など、さまざまな点について提案をしてくれる。

そのほかに、ページの読み込み時間の改善に大きく貢献する外部リソースがある。それは、DNSサーバーだ。

たとえば、ページで外部JavaScriptを読み込むのにDNSの解決だけに3秒もかかってしまっているとする。このページの表示を高速化するのならば、真っ先に検討すべき項目は、このJavaScriptが置かれているドメイン名のDNSサーバーを高速に動作するように改善することだ。

Accelerated Mobile Pages（AMP）の仕様に詳しい人には、ここまで取り上げてきたものの多くは非常になじみのあるものだったかもしれない。

AMPが存在するのは要するに、一般大衆はコーディングが下手だとグーグルが考えているからだ。そこでグーグルは、ページの読み込み時間1秒を達成するために、HTMLのサブセットを作成し、その背後にグローバルなコンテンツ配信網（CDN）を置いた。それがAMPだ。

僕個人としてはAMPに強い嫌悪感があるが、2016年の始めに多くの業界人が予測したように、グーグルはAMPを、メディア分野を超えて検索結果のあらゆるページに展開している。AMPのロードマップはさらなる展開を示唆しており、これが、われわれが取り組み利用していかなければならないものであることは間違いない。

ブラウズが始まる前からスピードアップできる

サイトのスピードを改善するため、ほとんどのブラウザは「ユーザーがリンクをクリックする前から、リンク先を先読みする」指示に対応している。

こうした指示をHTMLに含めておくと、「このページでは、後からあのファイルとあのファイルが必要になる」ということをブラウザに示すことができ。これによってブラウザは、そのファイルが実際に必要になる前にダウンロードの準備をしたり、場合によってはダウンロードまでしてしまうことができる。つまり高速に表示できるというわけだ。

Chromeは可能なときには自動的にこうした動作をするように細かく見ており、SEO側による指定を無視することもある。とはいえ、こうした指定は「rel="canonical"」タグと同じように動作し、効果がある可能性のほうが高い。

こうした指定には、「preresolve（dns-prefetch）」「preconnect」「prefetch」「prerender」がある。

画像：グーグル

rel="preconnect"（事前接続） ―― この指定は、「クライアントとサーバーの間のDNS解決」「TCPのハンドシェイク開始」「TLSトンネルのネゴシエーション」といったネットワーク接続に必要な動作を、必要になる前に行えるようにする。
ほかに、DNSの解決のみを事前に行いたい場合には「rel="dns-prefetch"」を使うこともできる（preresolve、事前解決）。
preconnectの指定をしていないと、これらは同時にではなく、リソースごとに1つずつ行われるが、preconnectを指定するだけで0.5秒近く削減できる場合もある。
Chromeのデベロッパーツールのタイムラインを見てアイドル時間（Idle）が多い場合は、rel="preconnect"で削減できるかもしれない。
rel="preconnect"は次のように指定する。
```
<link rel="preconnect" href="https://example.com">
```
あるいは、rel="dns-prefetch"を使って次のように指定してもいい。
```
<link rel="dns-prefetch" href="example.com">
```
rel="prefetch"（事前取得） ―― この指定により、今後必要になるであろうページのリソースをあらかじめダウンロードさせられる。
たとえば、次にユーザーが表示するだろうページのCSSを読み込んでおきたい場合や、次のページのHTMLをダウンロードしておきたい場合には、次のように指定する。
```
<link rel="prefetch" href="nextpage.html">
```
rel="prerender"（事前描画） ―― すでに説明したPrerender.ioと混同しないでもらいたい。rel="prerender"は、次のページをあらかじめ読み込んで、描画まで完了させる指定だ。
実際には、ページと画像などのリソースをすべて非表示タブに読み込ませておく。ユーザーがそのURLへのリンクをクリックすると、ページがたちどころに表示されるというわけだ（ユーザー実際にそのページに行かなければ、その内容はメモリから削除される）。
rel="prerender"は次のように指定する。
```
<link rel="prerender" href="nextpage.html">
```
rel="prerender"については、僕の過去の投稿で、コード1行でサイトのスピードが68.35％も改善したことを紹介している。
rel="prerender"には注意すべき点がたくさんあるが、最も重要なのは、一度に指定できるのは1ページだけであり、Chromeのスレッド全体で1つのrel="prerender"しか指定できないということだ。僕の投稿では、GoogleアナリティクスのAPIを利用してユーザーが次に行く可能性が高いURLを推測する方法を紹介している。
ただし、Googleアナリティクス以外のアクセス解析を利用している場合や、ページ上に広告がある場合は、注意が必要だ。その広告配信システムやアクセス解析ツールは、事前レンダリングしただけでユーザーが実際にはそのページを見ていなくても、ページを実際に表示したものと間違えてカウントするだろう。その場合は、ページが実際に表示されるまで動作させたくないJavaScriptを、すべてPage Visibility APIを使って制御すればいい。そうすれば、事実上、ページが実際に表示されて初めて分析を実行させたり広告を表示させたりすることになる。
最後にもう1つ大切なことを。rel="prerender"は、Firefox、iOS版Safari、Opera Mini、Androidの標準ブラウザでは使えないので要注意だ。なぜこれらのブラウザに対応しなかったのかはわからないが、とにかく、モバイルデバイスへの利用はおすすめしない。
rel="preload"とrel="subresource" ―― これまでの例と同様に、rel="preload"とrel="subresource"でも同じページ内のものを必要になる前に読み込ませられる。rel="subresource"はChrome専用で、rel="preload"はChrome、Android、Operaに対応している。

最後に、Chromeは高性能で、ここで挙げたものすべてが使えることを覚えておこう。リソース指示があれば、Chromeは100％の確信をもってその指示どおりに作業できる。Chromeはアドレスバーへのあらゆる入力に基づいて一連の予測を実行しており、どこに事前接続して何を事前レンダリングすべきかを判断するため、その予測が正しかったかどうかを記録している。「chrome://predictors」を開くと、ユーザーの振る舞いに基づいたChromeの予測を見ることができる。

画像：グーグル

SEOはどこに向かっているのか？

有能なSEO担当者になるために必要なスキルを1人の人間がすべて習熟するのは難しい。

たとえば、あるSEO担当者は、テクニカルなスキルに非常に長けていたとしても、効果的なアウトリーチは苦手かもしれない。その逆も当然あるだろう。当然ながら、SEOはすでにそのような形でオンページSEOとオフページSEOに分かれている。しかも、必要とされるテクニカルなスキルはこの数年間、劇的に増え続けている。

ウェブやソフトウェアの開発スキル、さらには統計モデリングのスキルなど、テクニカル寄りのSEO担当者が常に優位に立てるスキルがたくさんある。

もしかすると、テクニカルSEOは、従来のコンテンツ駆動型オンページ最適化と正式に分けて考えるべき時なのかもしれない。必要なスキルセットの多くが、（少なくとも現段階では）SEOに特有のスキルだと考えられるものと言うより、ウェブ開発者やネットワーク管理者のスキルだからだ。一部の組織ですでに導入が進んでいる「SEOエンジニア」という役割について、業界が考えなければならない。

SEOエンジニアは、技術を活かせる部分をきちんと活用できるように、少なくとも次に挙げるものはすべて把握することが必要になるだろう。

ドキュメントオブジェクトモデル（DOM） ―― ウェブを構築する際、われわれフロントエンドの開発者がウェブを操作する方法を理解するためには、ウェブブラウザを構成するブロックの理解は必須だ。
クリティカルレンダリングパス ―― ブラウザがページをどのように組み立て、ページのレンダリングに何が関与しているのかに関する理解は、グーグルがいっそう積極的に求めてきているページ読み込みの高速化に役立つだろう。
構造化データとマークアップ ―― 提示される情報に対するグーグルの理解の仕方に影響を与えるためには、メタデータをどのように指定すればいいのかを把握する。
ページスピード ―― すでに説明した以外の、ページの読み込み時間に影響するコーディング要素とネットワークの要素を理解するというのが、当然、ページの高速化に向けた次の段階になる。もちろん、これはユーザー体験全般に影響するため、SEOにとどまる話ではない。
ファイル分析の記録 ―― 検索エンジンがウェブサイトをどのように見て回り、何を重要でアクセスしやすいものと考えているのかを知ることが、新しいフロントエンド技術の到来でますます必要とされている。
JavaScriptフレームワークのSEO―― フロントエンド開発に人気のあるフレームワークの1つを活用することによる影響を理解するとともに、HTMLスナップショットの使用がいつ、どうして、どのように必要になるのか、また、実施には何が必要なのかを詳細に把握することが絶対に必要だ。先日、ジャスティン・ブリッグズ氏がこの話題に関する知識の大半をひとつにまとめ、構成要素に分類した。これは一読をおすすめする。
Chromeのデベロッパーツール ―― SEOツールの中でもひときわ強力なツールであるChrome自体の理解が必要だ。Chromeのデベロッパーツールの機能と、サードパーティーのいくつかのプラグインを組み合わせることで、SEOツールが現在、分析できていないさまざまなものに迫ることができる。SEOエンジニアは、これまでこの業界で問われていない疑問に対して、その答えを出すために必要な物をすぐに作れなければならない。
Accelerated Mobile Pages（AMP）とFacebook Instant Pages ―― AMPのロードマップから何か言えるとすれば、AMPとFacebook Instant Pagesの仕様がよく似ているということだ。この2つが混じり合うことなく存在し続けることは難しいと僕は見ている。
HTTP/2 ―― このプロトコルによって、ウェブのスピードがどのように大きく変化するか、そして、HTTP/1.1からの移行がSEOにどう影響するかを知っておく必要がある。