[レベル: 上級] Trusted Web Activity (トラステッド ウェブ アクティビティ) を実装すると、Progressive Web App (PWA) のサイトを Google Play にアプリとして登録することができます。 Trusted Web Activity とは Trusted Web Activity（以下、TWA）を簡単に説明します。 TWA は、アプリの中にウェブページをコンテンツとして表示できる機能です。 2017 年の Chrome Dev Summit で発表されました。 試験的な公開でしたが、Android 版 Chrome 72 のリリースとともに正式に利用可能になりました。 アプリの中にウェブページを表示させると聞くと、開発に詳しい方は Chrome Custom Tab や WebView を思い出すかもしれません。 どちらもアプリのコンテ

[レベル: 中級] 昨日とおとといに続いて、今日も Chrome Dev Summit 2018 のセッションレポートをお届けします。 セッションのタイトルは “Speed Essentials: Key Techniques for Fast Websites” です。 昨日レポートしたセッションと同じようにモバイルウェブの高速化がテーマです。 しかし、こちらはより実践的な内容になっています。 パフォーマンス改善に非常に役立つテクニックが満載です。 パフォーマンス改善の優先対象は画像とJS、フォントの3つ モバイルウェブで 1 ページあたりデータ量が多いリソースは次の順番（HTTP Archive 調べ） 画像 (約 500 KB) JavaScript (約 380 KB) フォント (約 80 KB) この 3 つは Performance Budget（パフォーマンス バジェット）

[レベル: 上級] Service Worker の機能を利用することにより、Google は繰り返し行われる検索の結果を 2 倍速く表示するに成功したそうです。 VentureBeat（ベンチャービート）が報じています。 SW + Navigation preload で速度2倍 繰り返される検索にこの速度改善は適用されるとのことなので、Service Worker のキャッシュ機能を利用しているのでしょう。 キャッシュは Service Worker が持つ定番の機能です。 さらに、Navigation preload という仕組みを Google は Service Worker で構成しているとのことです。 状況によっては、Service Worker が起動するまでの時間がネットワークのレスポンスを遅らせてしまうことがあります。 結果として、ページの読み込みも遅くなります。 Na

[レベル: 上級] SEO に一生懸命に取り組んで精通したいのであれば、今後は JavaScript に詳しくなることを、Google の John Mueller（ジョン・ミューラー）氏は推奨しました。 SEO に強くなりたいなら JS を学ぶ reddit の SEO 掲示板に次のような相談が投稿されました。 SEO には JavaScript の知識はどのくらい重要か？ ミューラー氏はこのようなコメントを返しました。 今後数年にわたって、これまでの SEO の20年よりももっと多くの JavaScript に出くわすことになるだろう。テクニカル SEO に懸命になりたいなら、HTML は終わりにして JS をもっともっと学ぶ必要があるだろう。 しゃれた静的な HTML のサイトには利点があるから、なくなることはなさそうだ。しかしながら、実際のところは、 JS のフレームワークはいたる

[レベル: 中級] 【UPDATE】 この記事は事実を正しく反映していないことが判明しました。 こちらの記事で説明しています。 ページの読み込み速度をモバイル検索のランキング要因として用いる “Speed Update”（スピード アップデート）を Google は今月導入する予定です。 Speed Update は、本当に遅いページだけが影響を受けるアルゴリズムだと思われていました。 しかしながら実際には、速ければ速いほど評価が上がるアルゴリズムになっているようです。 Speed Update では、読み込み速度が速いと段階的に評価が上がる Speed Update の導入を事前アナウンスした公式ブログの記事は次のように説明していました。 The “Speed Update,” as we’re calling it, will only affect pages that delive

[レベル: 中級] ウェブページの表示スピードを計測するツールの PageSpeed Insights で、サイト全体を集計した速度データを調べられるようになりました。 これまでは、単一のページが検証の対象でした。 origin: コマンドで集計データをレポート サイト全体の速度データを集計してレポートを出すには origin: をドメイン名の URL の先頭に付けます。 僕のサイトであれば、origin:https://www.suzukikenichi.com で検証します。 僕のサイトは、全体としては「Fast」（速い）という結果が出ました。😃 あるいは、個別ページを検証すると、origin: コマンドを使うと集計データをレポートすることができるという説明が出てきます。 Chrome ユーザー エクスペリエンス レポートでは、このorigin（https://www.example

[レベル: 中〜上級] 純正のポッドキャスト アプリを Google は公開しました。 ウェブサイトで公開している音声コンテンツをこのアプリのなかで発見、再生してもらうことができます。 1か月前に、ポッドキャストの利用拡大に Google が取り組んでいるという記事を書きました。 やはり Google はポッドキャストの普及を本気で目指しているようです。 Google ポッドキャストで音声コンテンツ SEO Google ポッドキャスト アプリは世界中の Google Play で一斉公開されました。 日本語版ももちろんインストールできます。 Google アシスタントと統合されていて、帰宅途中にスマートフォンで聴いていたポッドキャストを家に着いた後は Google Home で聴くということも簡単にできます。 AI の機能を用いて、その人に合ったコンテンツをレコメンドしてくれます。 Go

[レベル: 上級] noindex タグを JavaScript によってクライアントサイドで挿入することが可能です。 Googlebot はきちんとレンダリングし処理できます。 しかしながらこの方法は、処理に時間がかかることがあるため推奨されません。 JS による noindex 挿入を推奨しない JavaScript によってクライアントサイドでレンダリングさせた rel="canonical" タグを Google は無視するということでした。 サーバーが返す HTML に rel="canonical" が存在している必要があります（実際には、クライアントサイドでレンダリングした rel=”canonical” も認識されるらしいことが検証からわかっている）。 一方で、rel="canonical"（と rel="amphtml"）以外の要素、たとえば noindex robots

[レベル: 上級] JavaScript で構築されたサイトのために Dynamic Rendering（ダイナミック レンダリング）と呼ぶ仕組みを Google はサポートするようになります。 米マウンテンビューで開催された Google I/O 2018 のセッションで Google の John Mueller（ジョン・ミューラー）氏が発表しました。 Google が現在サポートする JS サイトのための3つのレンダリング構成 JavaScript でレンダリングされたコンテンツを適切にインデックスするために、次の3つのレンダリング構成を Google は現在サポートしています。 Client Side Rendering（クライアント サイド レンダリング）――クライアント側、つまりブラウザまたは Googlebot がすべてをレンダリングする。Googlebot がレンダリングで

[レベル: 上級] JavaScript を多用しているサイトにとって嬉しい機能の提供を Google は計画しているようです。 次の2つです。 WRS のアップデート DOM の検証ツール WRS のアップデート WRS が近いうちにアップデートされそうです。 “WRS” とは “Web Rendering Service” の略で、Googlebot がウェブページをレンダリングする仕組みです（詳細はこちらの記事で解説）。 現在の Googlebot は、Chrome 41 相当のレンダリング能力を持っています。 しかし、Chrome 41 がリリースされたのは2年前（2015年）です。 この記事を書いている時点での最新のバージョンは 62 です。 僕たちの業界ではかなり古くなっていると言ってもいいでしょう。 Google の Ilya Grigorik（イリヤ・グリゴリック）氏によれ

[レベル: 上級] AMP キャッシュへのアクセスとオリジナルのページ（AMP含む）へのアクセスを同一認識できない問題を解決する手段を Google アナリティクスが提供しました。 AMP アクセス解析が抱えていた問題 Cookie を引き継ぐことができないため、同じユーザーであっても AMP ページに訪問したユーザーと通常のページ（非 AMPページ）に訪問したユーザーを異なるユーザーとして認識してしまう問題を、Google アナリティクスを含む AMP 対応しているすべてのアクセス解析ツールは抱えていました。 Google アナリティクスは、AMP ページ本体へのアクセスと通常ページ向けページのアクセスを同一視できるように5月に改善を加えました。 しかしながら、AMP キャッシュのアクセスは依然として異なるユーザーとして認識されたままでした。 ですが、AMP キャッシュへのアクセスであっ

[レベル: 中級] 8月後半に来日していた Google のGary Illyes（ゲイリー・イリェーシュ）氏は、ISM Spin-off #2 と Google Dance Tokyo 2017 の2つのイベントで Google SEO に関するたくさんの最新情報を僕たち日本のウェブマスターに提供してくれました。 Googleモバイルファーストインデックスの導入時期はいまだ決定せず、段階的な導入を検討 Googleモバイルファーストインデックス後はレスポンシブが唯一の選択肢か？ Googleゲイリーがアドバイスする画像SEOと動画SEOのベストプラクティス この記事では、ISM Spin-off #2 の AMA セッションで繰り広げられた Q & A についてレポートします（一部、Google Dance Tokyo での Q & Aも含む）。 AMA は “Ask Me Anythi

[レベル: 上級] ウェブページをレンダリングするときに Googlebot が利用する仕様を解説するページを Google はデベロッパー向けサイトに公開しました。 レンダリングする仕組みとして Chrome 41 相当の仕様を Googlebot は 実装しているとのことです。 Googlebot は Chrome 41 相当 解説ページは次の説明で始まります。 Googlebot uses a web rendering service (WRS) that is based on Chrome 41 (M41). Generally, WRS supports the same web platform features and capabilities that the Chrome version it uses Googlebot は、Chrome 41 (M41) に基づい

[レベル: 上級] AMP 対応をやめたとき、AMP コンテンツが Google 検索に表示されなくするようにする方法を Google はデベロッパー向けページに追加しました。 Google は3つの方法を説明しています。 僕の見解も交えながら、この記事で紹介します。 【方法1】Google 検索から AMP ページを削除 この方法を使うと、検索ユーザーにエラーを発生させることなく AMP ページが検索結果に表示されるのを止めることができます。 正規ページ (rel="canonical" で指定しているページ) の HTML コードから、rel="amphtml" を削除する AMP ページの URL を、対応する正規ページの URL に 301 リダイレクトまたは 302 リダイレクトする AMP ページがなくなったことを次のようにして確かめる Google 検索して AMP ページが

[レベル: 中級] この記事では、最近見つかった AMP のちょっとした変更（テスト含む）を3つ紹介します。 ドメイン名を「ソース」として表示 多くの場合 AMPは、オリジナルの URL ではなく、キャッシュの URL から返されます。 そのため、実際にはどのサイトを表示しているのかが不明瞭です。 そこで、オリジナルのコンテンツがあるページのドメイン名を Google は表示するようにしていました。 このドメイン名の前に「ソース」という見出しが今は付くようになっています。 ちなみに、英語では「From」（〜から）になっています。 日本語の「ソース」は、一般ユーザーにはわかりづらい用語のような気が、個人的にはします。 「ソース」に比べて英語の From はずっとわかりやすいのではないでしょうか。 ラベル追加に僕が気付いたのは数日前です。 最近の変更だと思うのですが、もし、もうかなり前からであ

[レベル: 上級] AMP プロジェクトは amp-bind を一般公開しました。 amp-bind は、“オリジントライアル”に参加したサイトで試験的に公開されていました。 しかし、すべてのサイトでもはや完全に機能します。 amp-bind でダイナミックな機能を実現 一般的に言って、AMP は、ニュース記事やブログ記事、レシピなど静的なコンテンツに向いています。 だれがいつ読んでも、閲覧中にどんな動作をしても、コンテンツは変化しません。 いつも同じです。 しかし、ユーザーのアクションに応じてコンテンツが変化する動的なページが現代のウェブではそこかしこに存在します。 EC サイトであれば、たとえば次のような動的な機能は当たり前です。 サイズや個数に応じた合計金額の変化 タップしたサムネイル画像に応じた拡大画像の切り替え 商品の絞り込みや並び替え サイト内検索 ところが、従来の AMP の

EC プラットフォームの Fastcommerce が AMP 対応で生み出した成果 Fastcommerce はブラジルで 35,000 社に、EC サイトのプラットフォームを提供するプロバイダです。 早い段階から AMP に対応しました。 当初は商品一覧ページだけを AMP 化していましたが、昨年12月には、チェックアウトに至るまでのすべてのプロセスで AMP を利用することに決定しました。 こちらは、Fastcommerce のプラットフォームで運用されている EC サイトの、SóGravatas です。 ネクタイをオンラインで販売しています。 AMP 対応することで、Fastcommerce のクライアントは全体として次のような成果を収めたとのことです。 80 近いストアが AMP 対応し、200 万ページ以上を公開 表示時間が 2.5 倍改善――3G 回線で 3〜4 秒かかってい

[レベル: 上級] Google は、シークレットモードでアクセスするすべての 非 HTTPS（通常のHTTP） ページに対して警告を表示する計画です。 今年の10月にリリースする Chrome 62 からの実装を予定しています。 この仕様が開発版 Chrome の Canary に一足早く実装されました。 「シークレットモードで HTTP に警告」のオプション シークレットモードで HTTP に警告を発する機能は、（まだ）デフォルトでは無効です。 chrome://flags/#mark-non-secure-as で有効にできます。 有効化するには、“Warn on HTTP while in incognito mode” を選択します。 有効にした状態で、HTTP ページにシークレットモードでアクセスすると「保護されていない通信」のラベルがアドレスバーの先頭に表示されます。 10月

[レベル: 上級] PWA を実装するとウェブサイトをネイティブアプリのように機能させることができます。 では、PWA とアプリが対等になるのなら、PWA サイトがアプリストアに掲載され、インストールできるようになる可能性はあるのでしょうか？ Windows ストアには PWA が掲載 Windows Store のアプリカテゴリでは PWA が発見できるようになります。 5月に開催された Microsoft 主催のカンファレンスで紹介されました（該当箇所は 34:26〜。スライドは 49 ページから）。 つまり、ネイティブアプリではないのに PWA がアプリとして掲載されるのです。 そして、そこからインストールできます。 Windows Store での PWA 登録は革新的な試みだとして Google I/O 2017 の PWA セッションでも取り上げられました。 Google Pl

[レベル: 上級] この記事では、先週参加してきた Google I/O 2017 で取り上げられた Twitter の PWA 対応の成功事例を紹介します。 PWA版 Twitter ―― Twitter Lite ここが新しい Twitter は PWA版のモバイルウェブである、Twitter　Lite を 4月にリリースしました。 1か月経過して、従来の通常のウェブ版 Twitter と比較して次のような違いが見られたそうです。 毎日、100万のアクセスがホーム画面アイコン経由 URLバーを非表示、ネイティブアプリのようなフルスクリーン画面 ロード時間が30%削減 スクロールはアプリのように滑らか いいねやリツイートなどのプッシュ通知も来る データセーブで転送データ量を70%削減 インストールは極小サイズ PWA はネイティブアプリではないのでインストールに必要なデータ量が非常に小さ