Core Web Vitalに関する連載の第9回目では、WordPressに取り込むことができるかもしれない次世代テクノロジーについて説明していこう。これらはまだリリースされてまもない技術であり、あるものは適用できるしあるものは導入が困難である。しかし、さらなる高速化を目指す人は知っておいて損はないだろう。
リソースヒント
リソースヒントはCSSの遅延読み込みで紹介したが、本稿の内容に深く関わるので、もう一度説明する。リソースヒントはクライアント（ブラウザ）がリソースをどのように扱うかのルールを伝えるものである。多くは <link rel="preconnect" href="https://example.com" /> のような型で記載する。
| 種類 | 意味 |
|---|---|
| preload | （即座に必要にならないリソースを）読み込んでおく |
| prefetch | Webページなどのリソースをあらかじめ読み込んでおく |
| dns-prefetch | リソースのDNS解決をあらかじめ行っておく |
| preconnect | DNS解決、SSLハンドシェイク、TCPコネクション接続まで行う |
Webフォントの読み込みで紹介した通り、DNSプリフェッチが有効な場合もある。また、プリフェッチは「HTMLページ自体をあらかじめ取得しておく」という手法なので、リンク先に利用するとほぼ一瞬でサイトが表示される。似たような技術としてInstantClickというJSライブラリがあり、ユーザーがリンクを押そうと思ってから実際に押すまでのあいだ(200ms-300ms)にAjaxリクエストでリンク先を取得しておくというものだ。
なんにせよ「必要になるものはできる限り先に読み込んでおく」という手法が存在しているということ、そしてこうした用語があることは知っておこう。
Native AMP
AMPについてはすでに紹介したが、Googleが提唱するのは”Native AMP” というもので、これはつまり「サイトの一部だけではなく全体をAMPにする」アプローチだ。AMPプラグインのサイトには対応テーマが記載されている。
AMPはAMP-HTMLと呼ばれる独自タグ（Webコンポーネントのようなもの）を使うが、JavaScriptは基本的にAMPが提供するものしか利用できない。カルーセルのようなよく見るコンポーネントから、Google Anlayticsのような計測ツール、そして広告まですべてAMP製のものを利用する。
AMPはGoogleが提供する高速化フレームワークであり、サイトの高速化に劇的な効果をもたらす。しかし、Native AMPでサイトを運用すると決めたら、サードパーティーライブラリやWordPressプラグインに選定にはかなり慎重になる必要があるだろう。この部分をうまくハンドリングできる、もしくは不要な機能を自分で実装するぐらいの開発力があるのならば、Native AMPでのWordPressサイト運用も悪い選択肢ではない。Native AMPのショーケースもあるので、気になる人はチェックしてみて欲しい。
ちなみに筆者が開発したテーマSide BusinessではAMPのクラシックモード（記事ページだけAMPバージョンを出す）にしか対応していない。プラグインとの互換性を考えると、テーマ作者にとってNative AMP対応はモチベーションが湧きづらい作業だ。
PWA
PWAはProgressive Web Appの略であり、モバイルアプリと同様の使い勝手をWeb技術で実現しようというものである。Google主導なのでAndroid端末などではインストールUIの改善などがなされているが、iOSだと「ホーム画面に追加」をわざわざしないといけないので、「PWAはアプリである」という認識は一般的には浸透していないだろう。
PWAはキャッシュマニフェストやサービスワーカーなどを利用することにより、キャッシュとリソース先読みをフル活用するので高速化が期待できる。オフライン操作さえ可能だ。したがって、アプリとして使われるかどうか、そしてプッシュ通知ができるかという側面とは別に、PWAは高速なサイトを作るアプローチの一つだともいえる。日経新聞社の事例がPWAのショーケースとしてよく紹介される。
WordPressをPWA化するプラグインとしてはGoogleのChromeチームがリリースしているPWAのほか、PWA for WP & AMPや日本人（進藤さん）開発のPWA for WordPressがある。どれもPWAに必要なキャッシュマニフェストやサービスワーカーなどを提供するプラグインだ。
PWAでWordPressサイトを運用するのはまだ実験的なフェーズではあるが、PWAそのものはすでに実戦投入されている技術なので、挑戦してみるのは悪くないだろう。既存サイトは辛いかもしれないが、新規サイトなら取り組みやすい。ただ、それほど知見が溜まっている印象もないので、実際に取り組むとなったらそれなりに調べることは多そうである。
Signed Exchange
Signed ExchangeとはWeb Packagingという策定中の仕様の一つで、要するにCSSやJSなどのリソースにまとめて署名をすることで、リソースが分散されて配信される場合の正当性を証明するための技術である。
「どこで使うの？」というものだが、これはGoogleの検索結果に表示されたAMPのURLが https://google.com/amp... になる問題を解決する。また、Googleは検索結果においてSigned Exchangeに対応しているサイトをプリフェッチすると発表しているので、もし対応した場合は検索結果ページからの遷移が爆速になることが想定される。
Singed Exchangeはレンタルサーバーやマネージドホスティングでは提供されていないが、自分でサーバーを管理しているならGo言語のコマンドラインツールでゴニョゴニョすることで対応できそうだ。筆者はやったことがないが、ぜひ試してみて欲しい。
まとめ
ばらばたと紹介したが、本稿で学べることは以下の通り。
- ほとんどすべてGoogleが主導している技術である。
- ネットワーク負荷とリソースの読み込みこそが改善すべき点のようだ。
- コンテンツはキャッシュされ、Googleのサイト（AMP）やスマホの中（PWA）でホストされる。コンテンツはもはや運営社の手元（サーバ）にはない。
- Native AMPにすると自然と高速化されるが制限が増える。
- PWAにするとアプリのようになるが知見はあまりなさそう。
筆者のようなちっぽけな人間は自分のサイトの高速化に興味を持つが、Googleほどの巨人だとインターネットの高速化に興味があるようだ。実際にそれを実現可能なのもGoogleであり、巨人の肩に乗るのは悪いことではないだろう。
コメントを残す