00:04
はい、2月12日、12日日曜日、時刻は朝9時11分になりました。
昨日からまた東京に戻ってきて、いつもどおりの生活を始めています。
はい、おはようございます。耳のkeethことくわはらです。
では本日も朝活を始めていきたいと思います。
本日もですね、タイトルにあります通り、
Our Top Core Web Vitals recommendations for 2023ですね、を読んでいきたいと思います。
コアウェブバイタルですね、皆さんご用達というか、パフォーマンス界隈の中では。
ほとんどのウェブ業界の皆さんが指標にしているであろう基準になりますけど、
こちらの2023年版のコアなものです。
これがオススメですよというような設定があるので、これを見ていきたいと思いますが、
昨日はですね、LCPとTTFBですね、の2つを見てきました。
Largest Contentful PaintとTTFBの2つですね、というのを見ていきましたけど、
なかなか面白いお話なのと、一旦とデータに基づいたお話をされていて、
意外と皆さん設定してないんですよ、みたいなところがすごくありましたね。
で、LCPのほうは画像のお話が結構多かったなという印象がありますね。
画像の最適化をしていなかったりとか、初期に読まなきゃいけないリソースとして、
本当にそれがいりますかとか重要ですかみたいなところをしっかりやらないといけない。
それに対して意外とデータ配布にソースをつけたりとか、
あとレイジーですね、レイジーローディングの設定をしたりとか、
それのせいで遅くなっているというところがあったりするので、
それをやめたほうがいいよということでした。
あとは、イメージタグはちゃんとソースかソースセット属性を使ってくださいとか、
リンクですね、リンクタグのところにrel="preload",というのをせめてつけてねという。
最新の機能だと優先度をつけることができたりするんですよね。
Prioritizeというのがありまして、その優先度をつけることができるんですね。
リンクタグとかイメージタグにFetch Priorityというのを設定できるんですね、属性として。
それをHiにしておけば、HTMLを解析して、その後にCSSの解析して、
JSOを解析してというような処理をブラウザーするんですよ。
その前に先に抽象項目記を作るみたいなのが入っているんですけど、その中に。
その中の順番ですね。
で、画像をですね、Lazyとか、もしくはCSSの中でURLとかを書いたりすると、
その中でやっと画像を読み込みしたりとかするので、結構遅いんですよね。
ものによってはJSOの処理も終わってから初めて画像を読み込んだりするとかがあったりするので、
そうするんだったら先にFetch Priority Hiにしといたりとか、
Preloadというのをリンクタグにつけておけば、HTMLの解析のところで先にパッと読みに行くとか、
もしくはそれよりも先にPreloadで読みに行くみたいなこともできたりするはずなので、
その方がいいんじゃないの?というところでした。
やっぱりその画像の読み込みの速度が何だかんだ、
ウェブサイトの初期レンダリングのスピードに大きく影響するというのは、
皆さんもご用意いたしたと思うので、
その辺を見てみてくださいというのがまず一つというのと、
あとはですね、TTFBの方ではキャッシュをしてくださいとか、
03:02
もしくはCDNを使ってくださいみたいなところですね。
意外と世界中のサイトの29%のサイトはCDNから配信されていないみたいなデータがあるらしくですね。
Googleが持っているらしいです。
結構意外ですよね。
皆さん意外と使っていないというところなので、
やっぱりエッジサーバーから配信する方が早いよねというところと、
データがそんなに頻繁に更新されなかったり、
多少古くても問題ないんだったら、
キャッシュをしてそのキャッシュから返した方が全然いいよねという。
要はユーザーに対して、
データの更新がないにしても、
ちょっとだけ古いにしても、
早く返す方がユーザー体験はいいよねというのが昨日のお話でした。
この辺は結構皆さん自分でもやられていたりする方も結構多いと思うんですけど、
意外に世界中のサイトで数字を見るとやってないウェブサイトが多かったよというお話でした。
続いて今日は、
累積レイアウトシフトとも訳されますけど、
CLSですね。
カミュレイティブレイアウトシフトの話に入っていきたいと思います。
では早速入っていきましょう。
次の推奨事項というのは、
ウェブページの視覚的安全性の指標であるCLSですね。
カミュレイティブレイアウトシフトです。
CLSというのは2020年以降ウェブ上で大きく改善されましたが、
約4分の1のウェブサイトはまだ推奨される敷地を満たしておらず、
多くのサイトにとってユーザー体験を改善する大きな機会が残されています。
僕のCLSはあんまり意識したことがなかったりするし、
今までお仕事でもパフォーマンスを意識は必要しますけど、
いわゆるライトハウスの数字を向上するぐらいのところしかやったことがなかったので、
ちゃんとCLSを追うとかまで細かくやったことはなくてですね。
もしかしたら自分も今までの仕事でやってなかったことかもしれないので、
しっかり読んでいきたいと思います。
では早速ですけど、
ページから読み込まれるコンテンツに明示的なサイズを設定しましょうというところです。
レイアウトシフトは通常他のコンテンツの読み込みが終了した後に、
既存のコンテンツが移動したときに起こります。
したがってこれを軽減する第一の方法は、
必要なスペースを可能な限り事前に確保していくことですよねということでした。
なるほどね。
サイズの合わない画像によるレイアウトのズレを修正する最も簡単な方法というのは、
明示的にWidthとHeight属性、もしくは同等のCSSプロパティということなどを設定しておくことですね。
まあまあ確かに。
意外とやってないとこありますよね。
画像でかいやつをどーんとそのまま置いたりすることもよくあると思います。
しかし、HTTPアーカイブによると、72%のウェブページで少なくとも1つのサイズ未指定の画像が存在しますと。
ははーん。
なるほどですね。
全画像の中から1個くらい設定してないものがだいたい見つかるんですね。
72%のウェブサイトでそれが見つかっているよと。
これはすごいね。
こんなデータが出てくるのはなかなか面白い話ではありますね。
明示的にそのサイズを指定しないと、ブラウザーは初期状態で高さ0ピクセルを設定する。
あ、そうなんや。
画像が読み込まれて寸法が判明したときにレイアウトが一時的に変化する可能性もありますよと。
06:04
このことは集合的なウェブにとって大きなチャンスであると同時に、この議事で提案した他の推奨事項よりもはるかに少ない労力でこのチャンスを手に入れることができますと。
まあ確かにそうですよね。
単純に画像に唯一とハイト属性をつけるだけで一発でこの問題を解決する可能性が大いにあるというのは大きい話ですね。
ブラウザの設定によるとは思うんですけど、ブラウザベンダーごとに。
初期状態で画像の高さを0ピクセルにするというのは確かにね、少なくともChromeはやってるんでしょうね。
では続いていきましょう。
まあだいたい皆さんパフォーマンスのところの設定でやってないかつでも一番効果があるというのは結局コアなものは画像の扱いなんです。
はいでは続いて、ページがBFCacheの対象であるかということを確認するという項目ですね。
いきましょう。
ブラウザはbackスラッシュフォワード。
まあどっちもそうですね。
バックキャッシュフォワードキャッシュですね。
略してBFCacheと呼ばれたりします。
これなんか僕もつい最近名前知ったんだよ。
でも最近のこれは世界中ではデファクトらしいですね。
BFCacheと呼ばれるそのナビゲーションメカニズムを使用してブラウザ履歴の前または後のページをメモリースナップショットから直接瞬時に読み込むことができます。
BFCacheはブラウザレベルで重要なパフォーマンスの最適化であり、多くのサイトでCLSの大部分を占めるページロード時のレイアウトシフトというのを完全に排除することができます。
BFCacheの導入というのは2020年に見られたCLSの最大の改善を示しました。
にもかかわらずかなりの数のウェブサイトがBFCacheの適用を受けられず、多くのナビゲーションでこの無料のウェブパフォーマンスの恩恵を受けられないままになっています。
残念ですねこれは。
メモリーから復元されたくない機密情報を読み込むページではない限りは自分のページが対象であることを確認したいはずです。
サイトの所有者は自分のページがBFCacheの対象になっているかどうかを確認し、対象になっていない理由があればそれに対処する必要があります。
ChromeはすでにDevToolsにBFCacheテスターというのがありまして、今年はその同様のテストを行う新しいライトハウス監査だったりとか、現場でこれを測定するためのAPAなど、これらのツールも強化する予定です。
いやーありがたいですねウェブ。
ウェブの進化として開発者側によってくれる機能がこうやって生まれてくれたらすごくありがたいですね。
特にそのBFCacheテスターがあるというのは本当にいい話だと思いました。
BFCacheをCLSセクションに含めましたが、これはこれまでで最大の効果が見られたもので、BFCacheは一般に他のコアウェブバイタルズも回線しますと。
あ、そうなんや。これやることで他のやつも一気に回線する可能性があると。
これはページナビゲーションを劇的に回線するために利用できる数多くのインスタントナビゲーションのうちの一つになりますということでした。
はい。BFCacheを考慮するというのはすごく大事なことだと思いますので。
いやでもこれ本当にChromeの方がこの辺の機能を追加してくれているし、Lighthouseの監査にも入ってくれるというのはすごくありがたいので、
09:05
ぜひぜひこれを使っていきたいですし、他のブラウザーも同じような機能を入れてほしいなと思いますね。
BFCacheはもう、やっぱ最近の僕の調べで言われると無視全然できないお話だと思います。
無視戦略の話なので、そもそも無視はしないんですけど。
ですので、ここをちゃんと定量的に可視化されるというのはすごくいい話なので、
ぜひ本当は他のブラウザーも対応してくれればいいなというし、実はやっていたら最高だなと思いました。
では続いて、レイアウトを崩すようなCSSプロパティを使ったアニメーションもしくはトランジッションを避けましょうというのが次のお話です。
レイアウトがずれる原因としてもう一つよくあるのが、要素がアニメーションで表示される場合になります。
例えば、上部や下部からスライドして出てくるクッキーバナーだったりとか、その他の通知バナーとか、しばしばそれがCLSの一員となってしまいます。
これは、これらのバナーが他のコンテンツを邪魔している場合に特に問題になりますが、そうではない場合だとしてもバナーのアニメーションがCLSに影響を与えることがあります。
HTTPアーカイブのデータではアニメーションとレイアウトのズレを決定的に結びつけることはできませんが、
レイアウトに影響を与える可能性のあるCSSプロパティをアニメーション化しているページというのは、ページ全体と比べて良いCLSである確率が15%低いことが示されています。
15%は割と無視できない気がしますけどね。
いくつかのプロパティは他のプロパティよりも悪いCLSと関連しています。
例えばそのマージンやボーダーの幅をアニメートしたページのCLSというのは、ページ全体が悪いと評価される割合のほぼ2倍になりますというのは結構すごい話だな。
ページ全体が悪いと評価される割合のさらに2倍なのでそれよりもデカいんですね。
マージンとかボーダーの幅をアニメートしたページ。
マージンはよくやるけどボーダーもやるんか?アニメーション?あんまやるかもしれないですね。
ボタンとかがやったりするかもしれないですけど。
あんまこういうのやらない方が本当はいいんでしょうね。
レイアウトを誘導するCSSプロパティを遷移させたりアニメートさせたりすると、
必ずレイアウトが崩れ、そのレイアウト崩れがユーザーインタラクションから500ミリ秒以内でなければCLSに影響を与えるからです。
開発者によっては驚くかもしれませんが、これは要素が通常のドキュメントフローから外れる場合にも当たる範囲もあります。
例えば、絶対値の要素でトップやレフトをアニメーション化すると、他のコンテンツを押しのけていない場合だとしてもレイアウトが変化します。
しかしトップやレフトのアニメーションの代わりに、
transform://translateXというメソッドだったりtransform://translateYメソッドをアニメーションさせると、
ブラウザーがページのレイアウトを更新しないのでレイアウトがずれることはありません。
ブラウザーのコンポジタスレッドで更新できるCSSプロパティのアニメーションを優先することは長い間パフォーマンスのベストプラクティスとなってきました。
そうなんですね。不勉強で申し訳ないです。
また、一般的なパフォーマンスのベストプラクティスあることに加え、CLSの改善にも役立ちます。
12:03
一般的なルールとして、ページレイアウトを更新するためにブラウザーを必要とするCSSプロパティは、
ユーザーのタップやキー操作、もしくはホバーを除きますと反応する場合を除き、
アニメーションやトランジッションを行わないでください。
また、可能な限りCSSのトランスフォームプロパティを使用して、
遷移やアニメーションを行うようにしてくださいということでした。
ページレイアウトを更新するためのCSSプロパティはなるべく使わないでください。
ホバーを除いて、ユーザーのタップやキー操作などは除いてください。
ホバーはまあ確かにそうですけど、キー操作とかタップ操作って何かしらの、
あれですね、ネクストアクションを誘発するものなので、
それに対するアニメーションっていうのはなるべくやらなくて、
このページ内でもう留まる、特に遷移することもなかったりするものとか、
API通信することがない、そういうものに関しては別にいいのかもしれないですけど、
でもやっぱそのレイアウトが崩れたりするっていうものは基本的には避けてください。
やるんだったらトランスフォームプロパティを使ってってことですね。
そもそもそのアニメーション本当に必要ですかどうかっていうところの議論からやってもいいかもしれないですね。
ただそのボーダーよりもマージンパーティング周りを動的に変化させたりするものであれば、
それはレイアウトが崩れる可能性が大いにあるので、
そういうものはなるべくセンシティブにちゃんと設計考えて使うのがいいんでしょうね。
またライトハウスの感想の中に、
アボイドノンコンポジティブアニメーションっていうのがあるらしくて、
そういうものがあるので、
これは遅い可能性のあるCSSプロパティのアニメーションをページで使用している場合に
その傾向も発してくれますので、
今この辺も見てみてくださいということでした。
以上でCLSのお話が終わりですが、
主に画像の話とCLSのレイアウトのお話ですね。
まさにCLSなんでレイアウトなんですけど、
プロパティとかのお話でした。
いやこれもこれで結構勉強になりますねやっぱり。
やってなかったりしたら本当これちょっとやれるだけでだいぶ改善するし、
CLSだけじゃなくて他のものも一緒に解決してくれる可能性が多いので、
これを見てよくのいいかもしれないですね。
いろいろこの記事内でも、
それぞれの項目だったりお話の中に出てきた名前の別の記事のリンクが
ガーッと貼られていたりしますので、
この辺も見ていただければいいんじゃないかなと思いますし、
この朝活でもせっかく読んでる記事があるんですけど、
この記事の他のリンクももし読めるんだったらやっぱり読んだ方がいいなと思ったりしましたね。
毎回英語記事読んでるんですけど、
他の記事のリンクはありますよしか自分は言っていなくて、
僕何だかんだ後で読むと言っておきながら、
あんまり読めてない記事の方が圧倒的に多いので、
これはやっぱり反省としてしっかり読んでいきたいなと思う主題ではありますね。
では戻りまして、続いての項目、
ファーストインプットディレイ、FIDの項目に入っていきたいと思います。
さあ今日の朝活でこの記事が終わり、読み切れない可能性がちょっとありますね。
あともうちょっとなのですいません。
もう走り切りますよ。ちょっと長いかもしれないですけど申し訳ないです。
では続けていきましょう。
ファーストインプットディレイですね。
最初の入力の遅れっていうふうに迷惑されますけど。
最後の推奨事項というのはファーストインプットディレイ、FIDで、
15:01
これはユーザーのインタラクションに対するページの応答性を評価するものになります。
現在ウェブ上のほとんどのサイトがFIDで非常に良いスコアを出していますが、
私たちは過去にFID指標の欠点を記録しており、
サイトがユーザーインタラクションに対する全体的な応答性を改善する機会がまだたくさんあると信じています。
私たちの新しいINP、Interaction to Next Paintという指標はFIDの後継となる可能性があり、
以下の推奨事項はすべてFIDとINPの両方に等しく適用されます。
特にモバイルではFIDよりもINPのほうがパフォーマンスが悪いことを考えると、
FIDが良好であったとしても開発者はこれらの応答性に関する推奨事項を真剣に検討することをお勧めします。
インタラクショントゥネクストペイントですね。
ユーザーが操作した後の次のペイントですからね。
ではでは、今回はいくつかの項目に分かれているんですけど、まず一つ目ですね。
一つ目は、Avoid or Break Up Long Tasksですね。長いタスクは避けるか分割しましょうという話です。
タスクとはブラウザが実行する個別の作業のことです。
タスクにはレンダリング、レイアウト、パース、スクリプトのコンパイルと実行などがあります。
タスクが長い場合、大体50ミリ秒以上ですね。
メインスレッドがブロックされて、ユーザーの入力に素早く反応できなくなります。
ウェブアルマナックによると、開発者は長いタスクを回避したり分割したりするためにもっと努力できるはずだという証拠がたくさんあるそうです。
長いタスクを分割することは、この記事の他の推奨事項ほど労力がかかりませんが、
かからないかもしれませんが、この記事では紹介されていない他のテクニックよりは労力がかかりません。
JavaScriptでは常にできるだけ少ない作業で済むように努力すべきですが、
長いタスクを小さく分割することでメインスレッドをかなり助けることができます。
レンダリングの更新や他のユーザーとのインタラクションをより迅速に行うために、
メインスレッドに頻繁に降伏することで、従うことで交流実現できます。
IsInputPendingというものがあるんですけど、これはユーザー入力が保留されているかどうかを示すブルーチを示す関数になります。
あ、そんな関数があったんですね。
IsInputPending。
それを返した場合はメインスレッドに移行して、
交流中のユーザー入力を処理できるようにすることができます。
また、SchedulerAPIというのがあって、
これはより高度なアプローチで実行中の作業が他のユーザーの目に見えるか、
バックグラウンドにあるかというのを考慮した優先順位システムに基づいて、
作業をスケジュールすることができるようになります。
SchedulerAPIですね。
長いタスクを分割することで、ブラウザーはインタラクションの処理と、
それに伴うレンダリングの更新など、
ユーザーの目に見える重要な作業を行う機会を増やすこともできますということでした。
IsInputPendingは本当に知らなかったですね。
SchedulerAPIは名前しか知らなくてすみません。
僕もこれ、ちゃんと使いこなせていないので、
本当に反省というか、
新しく示されたので、ちゃんと自分もやってみたいと思います。
では続きまして、
次はですね、不要なJavaScriptを避けるというところです。
18:00
続いて、ウェブサイトでは、
かつてないほど多くのJavaScriptが配布されており、
この傾向がすぐに変わるとは思いません。
JavaScriptが多すぎると、メインスレッドの注意を引くために、
タスクが競合するような環境を作り出してしまいます。
本当そうですよね。
これは特に重要な起動期間中に、
ウェブサイトの応答性に確実に影響を与えます。
しかしこれは解決不可能な問題ではありません。
いくつかの選択肢がありますよと。
大きく3つありますね。
1つ目は、Chrome DevToolsのカバレッジツールを使用して、
ウェブサイトのリソースで使用されていないコードを見つけます。
起動時に必要なリソースのサイズを小さくすることで、
コードの解析とコンパイのかかる時間を短縮し、
初期のユーザーエクスペリエンスを向上させることができます。
これは本当そうですよね。
読み込むリソースが小さいんだったら、それに越したことはありませんし、
使用されていないコードがあるんだったら、
それはやっぱり削除しておくのがいいと思います。
この辺は、昨今のバンドルツールの中に、
アナライザーが一緒に付いていることもありますので、
スクラックもアナライザーが多少内包されていた気がします。
スクラックともサードパーティーのライブラリが、
結構有名なやつが一個あるので、それを使うといいと思いますし、
他のバンドラーも最近だと全然アナライザーができるはずなので、
そこから不要なものをどんどん削除するというのは全然いいと思いますね。
続いて、カバレッジツールを使って見つけた未使用のコードというのは、
起動時に実行されなかったために未使用と表現されているものもありますが、
将来的に何らかの機能を実現するためには、
まだ必要なものだったりする可能性は大いにあります。
このようなコードは、そのコードスプリッティングによって、
別のバンドに移動させることができますということで、
これはいわゆるチャンク分けに近いところですね。
ちゃんとスプリッティングをしておくことが大事ですよということでした。
必要なところで、必要なスクリプトを読み込めるような
設定とかバンドルをする方が大事だよねという話です。
続いて3つ目ですけど、タグマネージャーを使用している場合は、
タグが最適化されているかどうか、あるいはまだ使用されているかどうか、
定期的に確認するようにしてください。
未使用のコードを含む古いタグというのは、
タグマネージャーのJavaScriptをより小さく、
より効率的にするために消去することもできますと。
あと最近はですね、確かまだメジャーバージョンではないし、
スタッフはそんなに多くないんですけど、
PartyTownっていうサードパーティーのライブラリーがあります。
これを使うと、タグ系の処理っていうのをレンダリングした後にとか、
裏で実行させておいて、メインスレッドのところの処理を
ブロックしないようなことをやってくれるライブラリーがあります。
PartyTownってやつですね。
それによって、メインのところはメインでやってて、
余ったリソースとかで裏で進める。
もしくは終わった後にやってくれるみたいなことに反応してくれるので、
本当にありがたいんですよね。めちゃくちゃ便利で。
これ多分今年流行るんじゃないかなと思いますけどね。
PartyTownでもあるので。
見てみてくださいってことです。
では続いて、
次は、これがラストですね。
ラストのお話ですね。
FIDのラストのお話ですけど、
大規模なレンダリング更新を避けましょうってことです。
ウェブサイトの応答性に影響を与える可能性があるのは
JavaScriptだけではありません。
レンダリングはそれ自体が高価な作業の一種になります。
21:00
レンダリングの大規模な更新が発生すると、
ユーザーの入力に反応するウェブサイトの能力が妨げられる可能性があります。
レンダリング作業を最適化するのは簡単なプロセスではなく、
何を達成しようとしているかに左右されることがよくあります。
それでもレンダリングの更新を合理的に行い、
長いタスクにならないようにすることができることがいくつかありますよってことです。
それが3つありまして、1つ目ですね。
RequestAnimationFrameのメソッドの呼び出しっていうのは、
イベントループのレンダリングフェーズで処理され、
このステップで多くの作業を行うと、
レンダリングの更新が遅れる可能性があります。
RequestAnimationFrameを使用する作業っていうのは、
レンダリングの更新に関連する作業のみに限定することがとても重要ですってことです。
そもそもこれそんなに使ってるサイトってあるのかな?
僕あんま見たことがなくて、仕事であんま使ってないだけなんですけど、
裏で使ってる可能性も多いにあるし、
他のメソッドが内部的に使ってる可能性ももちろんあるので、
そういうイベントループの処理をやるんであれば、
なるべく避けるか限定的な作業にした方が絶対いいのは、
それは本当にそうだと思いますね。
かなりメモリー意外と使えると思うんだよね。
続いて2つ目です。
2つ目はDOMサイズを小さく保ちましょう。
DOMのサイズとレイアウトの作業の強度には相関関係があります。
レンダラーが非常に大きなDOMのレイアウトを更新する必要がある場合は、
レイアウトの再計算に必要な作業量が大幅に増加する可能性があります。
これはもうみんな知ってる通りだと思いますけど、そのまんまですね。
最後3つ目。
CSSコンテインメントを使用しましょうということです。
このプロパティはレイアウトとレンダリングの範囲を
DOMの特定のルートに分離することも含め、
そのコンテインプロパティが設定されているコンテナに対する
レイアウト作業の方法についてブラウザーに指示を出します。
これは必ずしも容易な作業ではありませんが、
複雑なレイアウトを含む領域を分離することで
必要のないレイアウトやレンダリング作業を行うことを避けることができます。
なるほど、CSSコンテインプロパティですね。
ちゃんと僕も使いこなしてるかというと自信ないですし、
そもそもCSS僕弱いので、
これはちゃんとやっぱりやらなさなきゃいけないなというところでした。
じゃあ最後ですね。
はい、ついに結論に行きます。
コンクルージョンですね。
はい、じゃあ最後ですね。
結論に行きたいと思います。
ページのパフォーマンスを向上させることは、
特にウェブ上で検討すべきガイダンスが山ほどあることを考えると
困難な作業に思われるかもしれません。
しかし、これらの推奨事項に焦点を当てることで
焦点と目的を持って問題に取り組むことができ、
あなたのウェブサイトのコアウェブバイタルの針が動くことを期待できます。
ここに挙げた推奨事項というのは決して簡単なものではありませんが、
ウェブの状況を慎重に分析した結果、
これらの推奨事項が2023年に
サイトのコアウェブバイタルのパフォーマンスを向上させる
最も効果的な方法であると確信しています。
ここに挙げた推奨事項以上のことを行いたい場合は、
以下の最適化ガイドを採証してください。
それぞれ記事のリンクがあります。
全部オプティマイズというのが頭について、
LCP、CLS、FID、INPの4つのページが用意されていますので、
それを見てみてください。
新しい年、そしてすべての人にとってより早いウェブに完敗ですと、
あなたのサイトがユーザーにとって最も重要な
24:01
あらゆる面で拘束でありますように、
この記事は締められておりました。
というところで、とっても勉強になりましたね。
自分たちがちゃんとやっていたこともあったり、
意外と僕らが知らないままツールが勝手にやってくれたことも
確かにあったりとか、いろんな気づきだったり、
お知らせがあってよかったなと思いますし、
僕らがやってきたこととして間違ってなかったな
ということもいくつかあったので、
いろんなものを気づけて、
いい記事だと本当に感謝の一言になります。
Googleさん、今年もよろしくお願いします。
ということで、皆さんも自分のサイトとか、
自分たちが開発しているサイトがどうなのかというのも
また見直しを図りつつ、
お互いに良いものを作っていけたらいいと思いますし、
お互いにこういう知見を共有し合えたらいいなと思っておりますので、
今後も何とぞというところで、
今日の朝方は終了したいと思います。
はい、では日曜日ですね。
今日もゆっくり休んで、
また明日、月曜日からまた1週間頑張っていけたらと思います。
それでは終了したいと思います。
おやすみなさい。
