2021年3月 Archives

LCPでもウェブフォントを諦めないで

2021年3月 1日 06:12|

コアウェブバイタルがSEOランキング要因になりますが、ウェブバイタルズのひとつである「LCP」の関連で、サイトの表示速度をいかに高速化するかに関心が集まっています。

このサイトの高速化には、レンタルサーバーのスペックや広告関連のスクリプト、あるいは画像サイズなどが関係してきますが、リソースのダウンロードサイズをいかに削減するかが重要なポイントとなります。

・広告関連のスクリプト
・サードパーティーのスクリプト
・画像
・ウェブフォント
・HTMLやCSSのファイル容量（※ミニファイ化）

このなかで、ウェブフォントはなしで済まそうと思えば、無しでも特に問題はありません。デフォルトのメイリオなどのフォントでも機能しますし、むしろ使用していないサイトも多いかと思います。

もしくは、MacとWindowsで標準インストールされている游ゴシックを使用する選択肢もあります。

逆に、使おうとすれば、おおむね500KB～1,000KB程度のダウンロードサイズを消費する形になってしまいます。

個人的には、サイドのダウンロードサイズは多くても2,000KBまで、できれば、1,000KB以内に抑えないと表示が重くなると感じています。

これが、ウェブフォントを使用すると、これだけで1,000KBを超えてくるケースも多いです。画像やHTMLファイル、各種の広告スクリプトも含めるとおおむね2,000KBは超えてくるものと思います。

ここまで大きくなると、LCPの関係上、ウェブフォントの使用を断念せざるを得なくなるかもしれません。

ただ、当サイト運営者はウェブフォントを個別サブセット化することでLCPに対応することにしました。サブセット化した場合、ウェブフォントのサイズが200KB程度に収まるため、少し大きめの画像１枚分程度で済むことになります。

これだと、Adsenseで自動広告などを使用していたとしても、おおむねサイト全体で800KB以内、おおくても1000KB程度に収めることができます。

LCPの関連でウェブフォントがネックになっている方は、サブセット化も検討されてみるとよいでしょう。

人はなぜリンクするのか？～被リンクの源泉は「アクセス数」にあり～

2021年3月 4日 17:26|

SEO対策においては被リンクの獲得が重要になりますが、オーソリティーサイトからリンクをもらうと検索順位が上昇するといわれています。

逆にいえば、リンク元のオーソリティー性が重要になるわけですが、オーソリティーであるならば、最低限、そのサイトにはアクセス数が発生していることが絶対条件となります。そのため、アクセス数の全くないサイトから被リンクを受けていてもあまり意味がありません。

また「被リンク＝アクセス数」の関係において、そもそもアクセス数の少ない状態では被リンクの発生しようがないという原因もあります。

人はリンクをする際、そのページを認識していなければなりませんが、そもそも検索結果で表示されていない状態では認識のしようがありません。

つまり、検索結果で上位表示されるからリンクされるのであり、月間10万ページビュー程度でもあれば、黙っていても月に100本、200本程度の被リンクは増えていくものです。

富める者はますます富み、貧しきものはますます貧しくなる、インターネットはそういった悪循環の仕組みになっているわけです。

それではどうすればよいのかといえば、最低限、ある程度のページビュー数が発生するまでは自力でそこまで持っていかないと、検索経由のアクセス数自体が発生しないという状況に陥ってしまいます。

ただし、一旦、上位に表示されれば、そのあとのサイト運営は比較的、楽になっていくものと思います。

個人的には、この負の悪循環を止めるためにも、検索アルゴリズムにおいて補正すべきと考えていますが、現状では上位表示したもの勝ちの状態になっているものと思います。

<HEAD>内の要素はどの順序で記載すべきか？

2021年3月 6日 16:41|

<HEAD>タグ内には、<title>や<meta>、CSSなど様々なタグがありますが、これらの順序はどのように記述すべきでしょうか？

まず一番最初に記載すべき要素についてですが、やはり<title>タグが最初と考えてます。大手メディアなどを参照しても一番先は<title>となっているケースが多いですし、一番最初に書くべきは<title>でほぼ間違いはないでしょう。

この<title>タグに対して、<meta name="description"や<meta name="keywords"などについては無くても機能しますので、titleタグよりも重要度ははるかに劣るものと感じています。特にmetaキーワードについては、各国の主要な検索エンジンでは利用されているケースもあるかもしれませんが、Googleについては既に意味はなくなっているため、記載してもあまりメリットはないかもしれません。

また、descriptionについては、serpで表示された際の使い方がメインになりますし、インデックスが更新されるまでは検索結果では反映されないため、今すぐ直ちに必要なわけでもないはずです。

気をつけるべきはJavascriptですが、先頭の方にこれを書いておくとそこで読み込みが止まるため、できるだけ後の方に持っておくのが一般的かと思います。

また、CSSについては同時に並行して読み込まれますが、ダウンロードするまではレンダリングが始まらないため、今すぐ必要な緊急性という面で考えると、descriptionやkeywordよりも先にCSSを記載すべきとも感じています。また、もしCSSを記載するならば、そのCSSよりも前に<link rel="preload"や<meta name="viewport"の方を先に記載すべきかもしれません。

そのため、個人的にはtitle→viewport→preload→CSS→description→keywordの順番でもありかと思います。

ただ、この「titleとdescription、keyword」の３つについては、昔からセットで記載されてきましたので、「title、description、keywordの３セット」→「viewport、CSS」といった順で記載するのがぶなんかもしれません。

次に、OGPタグを記載するのもデファクトスタンダードとなりつつありますが、こちらも今すぐその場で必要というわけでもありません。

シェアされてからタイムラインで表示されるのに数秒遅れるぐらいでは何の影響もないでしょうし、そもそもシェアされるかどうかも分からないため、OGPタグについては一番最後に記載しておけばよいでしょう。

また、OGPタグの"og:url"についてはURLのカノニカルタグになるため、本家のrelカノニカルの「<link rel="canonical"」については、OGPタグより前に記載するべきかと思います。

また、<link rel="canonical"を記載するならば、その次にAMPページの<link rel="amphtml、ガラケーページの<link rel="alternate" media="handheld"と続けてまとめて記載するのがスマートかもしれません。

まとめますと、「title、description、keyword」→「viewport、CSS」→「canonical、amphtml、handheld」→「OGP関連のタグ」→「Javascript関連」といった順序がよいのではないかと考えてます。

迷いがあるのは、<link rel="icon"ですが、ChromeデベロッパーツールのPerformanceで確認する限り、こちらはonload後の読み込みとなっていたため、レンダリングや読み込みが完了した後で参照されるものと感じています。

アイコン画像はブラウザのタブなどにも表示されるため、その場で直ちに必要ではあるものの、CSSほどの緊急性はないのかもしれません。そのため、CSSの後でカノニカル正規化タグの前あたりがぶなんかなと感じています。

WEBフォントは何KBまでOKですか？

2021年3月19日 10:58|

当サイト運営者の場合、サイトのダウンロードサイズは広告関連でのスクリプトの負担が転送量の大部分を占めています。

特にアドセンス広告の読み込みの容量が大きく、概ね数百KB程度となっている傾向があります。

ひと昔前なら画像が主な負担になっていましたが、最近は画像よりも広告関連のスクリプトの負担の方が大きいです。

例えば、ヤフーのトップページをチェックしてみますと以下のようになっていました。

Script：36リクエスト：「583.4 KiB」
Image ：38リクエスト：「391.1 KiB」

合計で約１MB（1,000KB）程度のダウンロードサイズですが、すべての合計サイズは概ね1,000KB程度に抑えるべきと考えています。

この1,000KBのうち、どの程度までをWEBフォントに使えるのかでいえば、当サイト運営者の場合は300KB以内までと決めています。

WEBフォントは外部サービスからダウンロードするのだから、除外してもいい気もしますが、WEBフォントもサイトのサイトの転送量には入ります。

「バナナはおやつに入りますか？」みたいな議論になってしまいますが、訪問者にとって、それがサードパーティーのものであるか、そのサーバーからの配信であるかは関係なく、実際にかかる転送量が問題になります。

その点、なかにはWEBフォントのみで１MB程度、すべての合計で３MB以上を使用しているケースもありますが、これはモバイル環境のユーザーにとって負担になるはずです。

理想としては、WEBフォントのサブセット化で300KB程度におさえ、画像を300KB程度使用し、その他の広告やテキスト、CSSもろもろで200KB、合計で800KB程度のサイトに抑えるのがベストではないかと考えています。

LCPとCLSを比較

2021年3月24日 00:41|

コアウェブバイタルに関する指標に「LCP」と「CLS」がありますが、今回はこの二つを比較してみたいと思います。

・LCP（Largest Contentful Paint）
・CLS（Cumulative Layout Shift）

なぜ、LCPとCLSを比較するのかでいえば、この二つは「P」と「S」の違いしかなく非常に紛らわしいからです。

ページスピードの方はLCPだっけ？CLSだっけ？と迷うことも多いため、このふたつの違いを理解しておくことをおすすめします。

このLCPの「P」は「Paint」のPになりますが、ファーストビューの一番大きなコンテンツを表示（paint）するのに要する時間のことを指しています。

そのため、LCPは時間の秒を意味する指標になりますが、この数値が長いとなかなかページが表示されないため、ページエクスペリエンスが低下してしまいます。

できるだけ、短時間で表示されるように改善する必要がありますが、具体的には画像やスクリプト、フォントなどのリソースのダウンロード時間を短くするのが効果的かと思われます。

そして、このダウンロード時間を短くするには、リソースのデータサイズを縮小するのが効果があります。画像を圧縮して容量を削減したり、フォントをサブセット化したり、あるいは使用していないスクリプトを削除するとよいでしょう。

このLCPの次に、CLSが出てくるわけですが、こちらは「Cumulative Layout Shift」、つまり累積のレイアウトシフトのことを意味しています。

ページを表示してレンダリングされた後、コンテンツが移動してシフトすることがありますが、これには様々な要因が考えられます。概ね、ブラウザが再計算した結果、再度レンダリングしなおす際に位置がずれてしまうことが多いと感じています。

仮に、「不安定な表示面積」が全体の30％で「0.3」、その「移動距離」が50％で「0.5」だった場合、0.3×0.5で0.15という値が出てきます。

これがレイアウトシフトスコアと呼ばれるものですが、一般的にはCLSが0.1以下であることが良好とされています。

おおむね、画像などが大きくシフトする際はスコアが悪くなるかと思いますが、widthやheight属性を設定しておけば、それほど大きくシフトすることはありません。

LCPが時間の値で理解しやすいのに対し、CLSはインパクト的な測定値になるため、どちらかといえば、CLSの方が難解かもしれません。

最近では巨大な広告が表示されるケースもありますが、その際にレイアウトが大きくずれるサイトもあり、そのようなサイトは今後、検索ではヒットしづらくなる可能性があるかもしれません。

おおむね、「LCP」と「CLS」は以上のような概念になりますが、これらはLighthouseなどのツールで数値として測定可能なため、一度、検証されてみることをおすすめします。

スマホでNotoを使う必要性はあるのだろうか？

2021年3月29日 13:56|

PCサイトの場合、シェア的にはWindowsユーザーが多いため、私はデフォルトのメイリオではなく「Notoフォント」を使用することが多いです。

その一方で、モバイル端末のスマホサイトの場合、iPhoneユーザーのシェアが多く、この場合はサファリになるため、綺麗に表示される「ヒラギノ角ゴ ProN W3」を使うことができます。

この「Noto」と「ヒラギノ」を天秤にかけた場合、フォントの美しさという点では互角か、もしくはわずかに「ヒラギノ」に軍配が上がると感じています。そのため、あえて転送量が大きくなるWEBフォントの「Noto」をモバイル端末向けに使用する必要性はないと考えており、モバイル端末ではWEBフォントを無効にしています。

大手サイトを閲覧しても、おおむねWEBフォントは使用されていないことが多く、基本的にはメイリオが使用されています。個人サイト等でWEBフォントを使用しているケースも多いですが、それがかえって読みにくくなっているのではないかと感じることもあります。

そのため、個人的にはサイトでWEBフォントを使用する必要はないと感じており、モバイルサイトでは上記の理由でなおさらないと考えてますが、もし使用するなら、PCサイトでのみ表示されるようにするとよいでしょう。

フォント専用のCSSを作成し、 media="screen and (min-width:480px)">などと指定して、PCサイトでのみ読み込む形にすると最適化できると思います。

« 2020年12月 | メインページ | アーカイブ | 2021年11月 »