8/25に登場するchrome85でリリースされる「CSS content-visibility property」がとても気になる

 8/25にChrome85のstableが登場するわけですが、ここでリリースされるCSS content-visibility property。web.dev側でも記事が登場しましたが、コンテンツ版のlazy loadのような動きをするようで、とても気になっています。web.devの記事に違いが載っています。

  • display: none: hides the element and destroys its rendering state. This means unhiding the element is as expensive as rendering a new element with the same contents.
  • visibility: hidden: hides the element and keeps its rendering state. This doesn't truly remove the element from the document, as it (and it's subtree) still takes up geometric space on the page and can still be clicked on. It also updates the rendering state any time it is needed even when hidden.

要するにdisplay : noneだとレンダリングプロセス自体が行われないし、visibility : hiddenの場合はhiddenの状態でレンダリング処理が走ってしまう。ということでon screenまでレンダリング処理が行われないcontent visibilityというものが登場したという理解。

Chrome85に関する記事の中では

非表示の場合、その要素の中身（サブツリーまたは置換された要素の中身）は描画やヒットテストが行われないまま、CSS の包含関係が適用されます。そのため、レンダリングが最適化されます。

ということで、イマイチ伝わってきませんがweb vitalsを意識すると、そのうち強く推奨されるようになるかもしれません。モバイル版Android Chrome85でもページの速度を表示するように出来るようですし。

あとprefers-reduced-dataとtrust token apiについても、かなり気にはなっている。。。特にtrust token apiは今後話題になるかポシャるのか。。。ただ話題にのぼるのはまだ先だろうなと思っています。

Bing Webmastertoolsも少しずつ新UIへお引越し中

たまにはと思ってBing Webmaster Toolsを確認していたのですが、ページトラフィックなど一部のページでは新しいWebmaster Toolsへ移行した旨の表示がされました。

旧UIも旧Google Webmaster Toolsだったけど、新UIもGoogle Webmaster tools感出てますね〜。どうもBing、日本語の検索イマイチ感あるし個人的にはどこまで見ようか毎回迷うところです。SEOでSevere判定されているところは直そうか、直すまいか。。。そりゃ直しておいたほうが良い事は分かるのですが。

2020年6月のGoogle AnalyticsとSearch Consoleドキュメント系アップデート

Google Analytics

引き続きWeb + Appのドキュメントが強化されたイメージです。

Universal Analyticsなどからの移行の手続きもガッツリ増えましたがイベントまわりの説明がだいぶ詳細になった気がします。そろそろ移行が近づいている雰囲気だけは感じました。。。

Search Console

Google検索の仕組み

クロールの部分に関して、大幅に修正が入りました。

1

ページをレンダリングし、テキスト コンテンツとそれ以外のコンテンツ、および全体的な視覚的配置を分析して、そのページを検索結果のどこに表示するかを決定します。サイトが Google にとってよく理解できるものであれば、それだけそのコンテンツを必要とするユーザーに表示されやすくなります。

ページのレンダリングに関しては最新版Chromeが利用されることとなり、Web Vitals指標まわりのCLSにも関連してくるかもしれませんが単純にテキスト・コンテンツのレンダリングだけでなく全体的な視覚的配置の分析も行われるということが明確に書かれた訳ですが、レンダリングした結果Above the foldが広告で埋め尽くされたり、コンテンツが表示された後に非同期で広告が差し込まれたりしてコンテンツの位置が変化するものなど、視覚的配置要素が検索エンジン側にも評価されるという感じでしょうか。

サイトがGoogleにとってよく理解できるもの という表現はイマイチふわっとしていますが、構造化データを指しているのか、それとも自然言語処理的な文脈で例えばキーワードが詰まっていたりと不自然ではないかどうかなどを見ているということなのでしょうか。

サイトクローラビリティの部分ですと、まずは1点目

1

サイトのページが Google からアクセス可能なこと、および正しく認識されることを確認します。Google は匿名ユーザー（パスワードなどの認証情報を持たないユーザー）としてウェブにアクセスします。ページ上のすべての画像やその他の要素を、Google が正しく認識し、理解できるようにしてください。モバイル フレンドリー テストツールでページの URL を入力すると、簡単に確認できます。

視覚的配置を見ることからリソースをbotに対してブロックするなということが強調された形だと思います。

またコンテンツとして追加されたのが プライマリクロール / セカンダリクロール と ドキュメント の部分です。

プライマリクロールとセカンダリクロールに関しては多少誤解していたような気がしまして、本ドキュメントを読むと私達が通常クローラーと言われてイメージするものがプライマリクローラーで、セカンダリクローラーは例えばPCのクローラータイプでレンダリングした際どのように機能するかを判断するものとしています。

これはドキュメントの部分で、何となく概要は理解できるようになっている気がしますが、1プロパティ(ドメイン等)に所属するドキュメント(1コンテンツ)の束がまず存在し、そのドキュメントごとに正規のURLと代替URL(重複URL)のようなセットで持っていて、かつその正規・代替URL(重複URL)にはバージョンと呼ばれる「モバイル」「PC」「AMP」のフラグがついているというイメージのようです。代替・重複URLに割り当てられたページURLはクロール頻度が低下し、また代替URLのバージョンに「PC」が付いていた場合、PCのGoogle検索結果では正規URLではなく代替URLが検索結果に表示されるというわけです。

代替ページの検知はrel=alternateやrel=canonical、リダイレクトやリンクタグで検出され、重複ページは同一コンテンツが複数URLでアクセス出来る等によってGoogle側で重複とみなされるという感じです。少し感じるのは今まで以上にcanonicalやalternateによる事故にはもしかしたら気をつけたほうが良いのではないか?という点と、バージョンによる違いでGoogle検索結果が変わる可能性、つまりPCでの検索とモバイルの検索で結果が全く違うという状況となるような気がします。現在でも違うは違うのですがそこまで大きな違いというものではないと思っています。

逆に今まではどうやってたんだ？という雰囲気はありますが、単純にバージョンを持たずに全URLに対して重複コンテンツなのか？などを判定してフラグ付されていただけなのかもしれません。このあたりはよく分かりませんがGoogleがMFI移行後もPCから検索すればPCサイトが表示されますと言っている意味が分かりますね。

参考

Web Light

Web Lightのユーザエージェントが公開されました

Mozilla/5.0 (Linux; Android 4.2.1; en-us; Nexus 5 Build/JOP40D) AppleWebKit/535.19 (KHTML, like Gecko; googleweblight) Chrome/38.0.1025.166 Mobile Safari/535.19

ちゃんと調べたことは無かったのですがGAタグはPVのみ計測でイベントは計測されないという事なんですね。またrobots.txtは無視するということで、これは例えばGoogle検索結果に表示されたページを見ようとしたら一定以上読み込みに時間がかかりWeb Lightモードに切り替わって表示されるというケースの場合、対象のURLの閲覧をユーザが指定して開くから無視するという感じでしょうか。クローラーでも何でもないので、単純にウェブページを簡易化して見るためのプロキシというイメージで、特にそこに関してrobots.txtを適用する必要性は何もないと。

ここは日本でどのくらい表示されることがあるのか若干気になりますね。私自身、それほど良い回線環境ではないので時々Web Light表示は見かけます。。。

参考

構造化データ - speakableの構造化データテストツールでの見え方

日本語に現段階では対応していないのですがSpeakableをヘルプに沿って対応してみると一見エラーはなさそうに見えますが、必ず中身を確認して自分が思っていたデータがspeakableとして選択されていることを確認する必要があります。

ヘルプだと、こんな書き方がされています。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

{
  "@context": "https://schema.org/",
  "@type": "WebPage",
  "name": "Quick Brown Fox",
  "speakable":
  {
  "@type": "SpeakableSpecification",
  "xpath": [
    "/html/head/title",
    "/html/head/meta[@name='description']/@content"
    ]
  },
  "url": "http://www.quickbrownfox_example.com/quick-brown-fox"
}

このspeakableはxPathかcssSelectorのどちらかで設定が出来ることとなっています。xPathやcssSelectorでちゃんと対象が抜き出せているのかを確認する必要があるという話なのですが、最初に述べたとおりこのxPathやcssSelectorで適切にデータが抜き出せなくても現在エラー表示にはなりません。

中身を見るとxPathの場合、xPathの欄と適切に抜き出せていた場合は value 欄がありますが、適切に抜き出せなかった場合はこの value 欄がありません。ただ、その状態でもエラー表示にはならないということです。

私はxPathで実装したのですが、このspeakableで指定できるxPathはやや癖があるのか、何度も適切に抜きだされているかを確認しながら作業したのですが最終的にはChromeのDev Tools側でコピーできるxPathを基に作るのが一番早かったです。

Dev ToolsにxPathのコピーとFull xPathのコピーの2種類があります。どちらもspeakableには使えそうでしたが、少し注意点としては意外と(?)HTMLが定義に従って丁寧にかかれていないと抜き出す事が出来ないということくらいでしょうか。この点は試行錯誤しているときに気づいたのですが、 text() を使って抜き出そうとしても抜き出せない事もあったりして、当たり前なのかもしれませんが、ちゃんとHTMLがキレイに書かれているウェブサイトでないと上手く抜き出せないかもしれません。

Google検索で当たったバケットテスト - ファビコン復活・カードデザイン

Googleのバケットテストに当たる事はちょくちょくあるような気がしていますが、最近出会ったのはfavicon表示と検索結果1件ずつがカード型になったタイプです。favicon対応がリリース後一旦取り下げられましたが、次のデザインはどうなるのでしょうか？

Google検索結果表示

favicon付きデザインを見たときは、こういうブラウザ拡張昔あったなぁと懐かしい気持ちになりました 😄

Google検索結果のアンサーボックスから 'Scroll To Text Fragment' が導入されている

ChromeブラウザとEdgeがサポートしている「Scroll To Text Fragment」というものがありますが、早速Google検索結果のアンサーボックスのリンクで利用されるようになったようです。これは記事を多く持ったメディアあたりは大いに恩恵があるかもしれません。

この対応はもしかするとアンサーボックスの拡大と音声検索の強化が先に待っているのかもしれませんね。

検索結果例1(内容に他意はありません)

Google検索結果1

飛び先1

リンクURL : https://ideco.kddi-am.com/learn/words/260/#:~:text=余剰資金とは手持ち,のことを指します。

Google検索結果からの飛び先1

検索結果例2(内容に他意はありません)

Google検索結果2

飛び先2

リンクURL : https://toyokeizai.net/articles/-/356908#:~:text=60歳の時点で,といったメリットを受けられ

Google Analytics Demos & Toolsサイトの証明書問題は直ったっぽい

Google AnalyticsのCampaign URL Builderなどのツールが詰まったDemos ＆ Toolsが直ったみたいですね。。。

とは言っても、閲覧出来る端末もあったりして閲覧出来ない端末は何が原因なのかよくわかりませんでした。仕事で使っていたWindows端末だとChromeで見ても証明書のコモンネームの問題ということで閲覧すら出来ませんでした。。。 危なくても良いから閲覧する のようなオプションもなく全く閲覧する許可されず、時々使っていたサイトなので大変困っていました。

今は直ったようで助かりました。。。