おめでとうございます。このタイトルでセッションを始めたいと思います。まず少し自己紹介ですけど、先ほどもありましたように、Hitaretsで会社をやっておりまして、普段はデザイナープログラマ、ディレクターだったり、もちろん経営者でもあるんですけど、ワードプレイスとルビーオンレイルズ、リアクト、UCLIといった有名なドープンソースにもコンプレビューとしておりまして、自分自身もさっきもあったように、フォーカーという開発環境を作っていたり、ベースというテーマのテンブレットとか、いろいろ作っております。という感じで、これが僕のGitHubのプロフィール画面なんですけど、こうですね、ネイスブックのリアクトとレイルズとUCLIでブーテンベールっていう感じで、コントリビューとするとこういうふうに自分のプロフィール画面に載せられるんですよ。悪感ですよね。すごいですよね。自分ででもすごいなと思います。これが僕が作っている開発環境なんですけど、ドッカーベースの高速な開発環境でありまして、割とそれなりに人気で、GitHubでいういいねっていうスターみたいな機能があるんですけど、これは今475スターなんですけど、ちなみにこれスターしている方、これくらい出し合います。じゃあほら、いらっしゃいますか。ありがとうございます。残りの方たち、たぶん100名ぐらいいるかなと思うので、きっと足の朝には600ぐらいがなっているはずです。大丈夫ですか?もう一度、大事なので足の朝には600ぐらいスターになっていると思います。ワドクレスのちょっとした本を作っていたりですね、書いていたり、こちらはオープンソース遠征点もちょっと遅れていたりという感じでですね、書いています。Figmaっていうデザインするが大好きでですね、実はワドクレスのデザイン、カーネカーメンのデザインだったりサイトのデザインもFigmaで行われていますので、ぜひ触ってみるといいかなと思います。ちょうど機能がお届けくらいですね、最強の機能、オートレアオートっていう機能が出たんで、はい、来年500万円してください。最強のオーションというツールにハマっております。もうちょっと推奨しているので、どういうものかっていうのを見てもらえば、すごいなって、ちょっと感じてもらえたと思います。事故障が長いなこいつと思ってるかもしれないですけど、まだちょっと続きます。バーバー社長、おしゃぶり社長っていう感じでですね、たまりSNSでこういう感じのキャラクターとして登場しております。ということで、社内ではバーバーを書いておいて、予想ではおしゃぶり社長って言われているんですけど、さて本日のハッシュタグ、はい、バーバーを書いておいてです。ではなくて、こちらですね、WC大阪2019。はい、ぜひ色々ありましたらこのハッシュタグがつけて、シェアしてください。と、スライドは後ほど公開しますので、スライドに書いてある内容をゆっくり書いてあとに実践してもらえればいいと思います。では、早速始めたいと思います。から本題ですけど、はじめにWebパフォーマンスとは、なんといったことですけど、MDNWebToxっていうですね、Pyrofoxを作っているモジラさんが出しているトキュメントにこういうふうに長々と書いてあるんですけど、要は何かというと、表示速度ですね。で、Webパフォーマンスっていうのがなぜ重要化についてはいろんなソースがあるんですけど、Googleさんもちゃんとした記事を書いてありますので、ぜひこちらを読んでもらえればと思います。ここに具体的な数字も書いてありましてですね、例えば読み込む時間が短縮するとコンバージョンが上がったり、直径2が下がったり、セッションあたりのエズランスが上がったり、逆にそれが時間が3秒超えてしまうと、なんと半数以上のモバイルユーザーがですね、もうその訪問を諦めてしまうということが結構ね、ECとか直結しますよね、売り上げとかにも。かなり重要な仕事が一つではあるかなと思います。さらに我と最近のニュースなんですけど、Chromeがですね、速度が遅いサイトに対して名誉なバッチを表示しようかなということを検討しているらしいです。で、今回実際にあるサイトを実験として使ってですね、それのパフォーマンスを改善していこうということを行って、実はちょっと前に、何か月か前に別のところでやったセッションをちょっとブラッシュアップしたもので、その時の実践したことも少しブラッシュアップしております。使ったサイトというのはこちらのデザイナーさんだったらちょっと見たことあるかもしれないですけど、スピカグラフさんというですね、実はキテレズのチーフデザイナーをやっております。肩のブログなんですけど、まずは結果からお見せします。元々の数値、こんな感じです。右側の4つというのはパフォーマンスとは直接は関係ないです。一番左を見ていただくと若い数字が出てます。定数として30になっております。実践した後に対策をした後の、こんな感じですよね。右はついでにやったという感じですけど、ということはワードプレスを使っているんですけど、基本的にもうワードプレスのままです。今もそのまま上がっておりまして、特別なことというのは、基本的にはあまりしなくてもこれくらいまでは持っていけるんで、ぜひ試していただければと思います。この後、このWebページテストという別の計測ツールもあるけど、この中で出ております。この後、いろいろ色んな手法がいっぱい出てくるんですけど、分かるやつと分からないやつというのがあると思うんですけど、分からないやつは木を残してほかのできるやつからやっていただければと思います。まず、一番最初にパフォーマンスが改善するためには計測から始めないといけません。計測方法に関しては、いろいろありましていくつかのツールを紹介します。結構あるんですけど、さっと流していきます。まず、一番最初にワードプレスに公式のサイトヘルスというツールがあるんですけど、5.1から導入されていて、今も5.3でどんどん改善されていています。サイトヘルスに関してはパフォーマンスのみじゃなくて、この下の結果を見ていただいても分かるように、パフォーマンスに関するものとセキュリティに関する項目が出ておりますので、それに対してツールというところに入ると見れるんですけど、ちゃんとクリアしているかというのをチェックして対策していくことができます。次に、よく使われるライトハウスというもの。ライトハウスについて聞いたことないという方やしやすい。若干名ですね。ユメンスに入るGoogleが出している計測ツールで、Googleさんがやっている計測ツールの大元がライトハウスが入っている状態ですね。今の現時点で拡張としてダウンロードできるんですけど、バージョン番号が100ってなってるんですけど、本当かなと思って、ちょっとよくわからないんですけど、100ってなってるらしいです今。多分間違ってると思います。これは先ほどの結果、お見せしてました結果がライトハウスの結果なんですけど、パフォーマンス以外ですね、さっきも見たようにアクセシビリティ、エストプラクティス、SEOとPWAという項目は全部で5つの項目が出てますので、パフォーマンス以外の改善として計測することもできます。実はライトハウスはコマンドラインツールがございます。NPMでインストールすることができて、こちらが5.6なので、多分このバージョン番号の方が正しいです。こういうふうにライトハウスで後ろにURLを叩くと、なんとその黒い画面の中で結果が表示されて、さらに保存することがHTMLファイルとしてその結果を保存することができます。最近さらにこのライトハウスCIというものが出てきまして、中はおそらくライトハウスのCLIというのを使っていると思うんですけど、要するにCIとかDIを行うときに、この計測を一緒にすることができるようになっております。さらにChromeの中でデフォルトの機能としてオーディッツという機能があるんですけど、開発者ツールを開いて、この右側にちょっと小さいんですけど、オーディッツというタブがあるんですけど、そちらをクリックしていただいて、そうするとこの画面が出てくるんですけど、その下のRUNオーディッツというのを行うと、先ほどのライトハウスと同じような結果が表示されます。ということはChromeの場合は実は拡張機能をダウンロードインソールしなくて、このオーディッツというものをデフォルトのやつを使うことで、もう何だろう、計測することができます。ただ若干バージョン番号が拡張よりは少し低いという感じですね。で、他にですね、ウェブのサービスではあるんですけど、グループさんが出しているページスピードインサイトという、こちらのURLをアクセスするとこういう感じの画面が表示されて、そこに公開されているサイトのURLを入れると計測することができます。ただこちらのツールに関しては、パフォーマンスのみの計測になっております。バックペンドの中身的にはライトハウスを使っているんですけど、表示結果が実はその先ほどのオーディッツとかライトハウスと点数が若干違います。それは何かというと、ここに書いてあるようにですね、ChromeのユーザのExperience Reportのデータを紐紙して計測しております。これは何かというと、Chromeを使っているユーザが実際にそのURLにアクセスして、どういった帰ってきた結果を実際には何とこにも出ないんですけど、Chromeが一応それを収集して、それを紐紙してこのサイトが実際に早いかどうか、今の状態プラス過去の多分1週間くらいのデータを紐紙して表示しているので、若干オーディッツとかライトハウスよりは点数は低くなると思います。こっちの方が本当にアクセスしたときの状況に近いとは思います。さらにこれは公開されているサイトじゃないと計測ができないので、例えばローカル開発環境でページスピードインサイトは使えません。もう一個ですね、こちらがGoogleが出しているWordpressのプラグインでサイトキットというものがございまして、中身は基本的に先ほどのライトハウスとほぼ一緒なんですけど、要はサーチコンソールとかアナリティスとかそういったものをカニラミに表示することができるプラグインになっております。で、もう一個TestMySightというモバイルに特化したGoogleの計測ツールですけど、これも中身がどうなっているか分からないですけど、若干その点数とかじゃなくて早いか遅いかでくらいしか教えてくれないです。で、さっき一番最後に少し出たやつで、500ページTestというGoogleとは関係ないところが作っているもので、こちらですね、実際にそのページにアクセスして、しかもいろんな拠点から、日本だけじゃなくてローカルでもなくて、いろんな拠点からアクセスして、3回テストを行ってそれが平均を足して、いろんな項目も足してくれるような計測ツールですね。で、計測ツールいろいろあるんですけど、今回はどういうふうに改善していくかというと、一番やりやすいのがライトハウスかなということで、ライトハウスだと点数出る上にどこを改善したらいいかというのを細かく一応出してくれます。すごくやりやすい。最初に始めるのには一番いいツールかなと思うので、一応それを元に改善していった結果にはなっております。で、ここにも書いてあるように、もちろんですけど点数が高くてもですね、対反的に遅いサイトもあれば、結構早いじゃんと思ったサイトでも点数がめちゃくちゃ低いというケースもありますので、一応3個程度にと思っておられればと思います。ただ点数が低くてですね、改善しなくてもいいだろう、早くても改善しなくていいだろうということにはならないので、そこだけは料理していただければと思います。まず大きく分けて2つのセクションに分かれております。1つがこのコーディングナッシュでできる対策をやっていくのと、もう1個がもう少しちょっとプロート向けのコードを書いて改善していくという手法を2つに分けて改善します。一番最初にですね、まずはサーバーガラだということでですね、最初はそのサイトに関してはね、ここに乗っているサーバーではない別のサーバー、実名をちょっと出さないんですけど、お使っておりましてと思ってたので、もうこの際に引っ越ししましょうということで、いくつかのタルサーバーを検討しました。ここに検討項目が書いてあるんですけど、いろいろ検討しました結果、今回は多分スポンサーでもあるのかな、知ってますかね。Xサーバーさんのサービスを使って行うことにしました。ただ、実はこれ2、3ヶ月前に行ったものなので、その時のロリポップさんのスペックがちょっと違ってたんですよ。その時のロリポップさんのウェブサーバーがアパチカエンジンXだったような気がします。PHPもモジュール版だったと思います。SSDも一部だったと思うので、その間にですね、ロリポップさんのスペックが上がってですね、このアイトスピードっていうのになってちょっと苦しいなと思った次第です。それについてこれから少し解説しますが、ウェブサーバーに関してはアパチエンジンXあとWindowsのやつもあるんですけど、何がいいかっていう話なんですけど、お勧めはせめてエンジンXかなという感じなんですけど、こういう感じの図詳しくは解説しませんが、でもアパチよりも処理を同時に処理することに避けていて、こっちのほうがフォーマンスが出るんじゃないかなという感じです。さらに先ほどプレーたライトスピードというものですけど、第4のウェブサーバーというふうに言われておりますので、エンジンXとアパッチの良い所取りのウェブサーバーになっておりまして、アパッチと完全交換しますので、HTアクセスがそのまま使えるというふうになっております。ちょっとこれ良いなということで、いろんなサーバー屋さんに提案しております。もう一つ、HTTP2はこのご時世だったら必須だろうということで、こういう感じの解念です。他にもいろいろ先ほども書いてあるように、HTTP7も必須ですね。モジュールモードと、マストCGIモードと、LSAPIというのがライトスピードさんが出しているモードなんですけど、というのがあるんですけど、一応異端があるという状況で、そこら辺は少なくとも通常のCGIじゃなくて、そのどれかだったらいいかなという感じです。ハードディスクはもちろんですけど、SSDの方が早いです。詳細についてお伺いします。次にサーバーを移行した後にですね、不要なプラグインをアインストールしていこうということで、なんとデータベースをちょっと見たらですね、その時ですね、PHPMyAdminしか使えなかったので、こういう感じの画面になってるんですけど、なんかすげえ重いなと思って、データベースをエクスポートしするときになんだろうと思ったら、なんと見てください、これ。1000万両のレコードですよ。1個のデータで1.4GBなんですよ。なんだこれって思って、調べたらとあるプラグインでですね、ずっとデータをどんどん溜めていくようなプラグインでですね、基本的には不要なんですよ。実際のプラグインには出さないですけど、というのがあって、すごいなということで、すごくサービルですよね、これ。これについて、前回の別のところのイベントで質問をいただいたんですけど、このデータには実際パフォーマンスにそこまで影響するんですか?という質問をいただいたんですよ。まあ、あんまり影響しないかもしれないです、実際は。そこまでこいつのせいでサイトが遅くなる、というのはあんまりないかもしれないですけど、でもどう考えてもこれが、パフォーマンスに良い影響を与えることはないので、サクリをしましょう。ということで、不要のプラグインは基本的にはどんどんサクリをしていってください。最近のサイトヘルスの方にも出るようになってます。アクティブじゃないプラグインは、消した方がいいんじゃないの?という提案が出てくるので、ただ、この一番下に書いてあるように、プラグインの数とパフォーマンスには直接には比例はしないです。結局、100個のプラグインがあったとしても、そこに書いてあるソースコードがそんなに重くなければ、もちろんそんなにパフォーマンスによるとしないし、1個のプラグインで、すごい重い処理をしていたら、それはアケリキュアになります。次に、画像について、先ほどのブログに関しては、画像が結構いっぱいあったんですけど、一番適切な画像の処理を選んで配信することが重要になってきます。ここに、基本的にWeb上でよく使われている画像の形式について書いてあるんですけど、皆さんよくご存知はJPEG、アニメーションでよく使われるGIF、GIF、イラストとか、使われるPingとか、最近あるWebPというGoogleが開発している新しい種類の画像の形式と、ベクター式の画像タイプ。最近はほとんどのブラウザーでもサポートしているSVGという形式があるんですけど、基本的に上の青いところがラスタライズ形式と言われているもので、下のベクター形式というのがSVGということになっているんですけど、僕的にはですね、もうこのご時世だったら、イラストとかそういった形の色数が少ない画像であれば、もうSVGだけでいいかなという感じです。写真類に関してはJPEG、もしくはできるんだったらWebPというものを使った方がいいということなので、基本的にもGIFとPingの出番がほぼなくなってきているんじゃないかなと思っております。今回に関してはここにキャプチャーを載せているんですけど、こういう感じのイラストが載ってるんですけど、色数が少ないんですよね。要するに単色の部分が大きいので、さらにイラストレーターでこのデータを作ってるんで、要するにベクターのデータとして一応残ってるんで、ということで全部SVG関しました。ワードプレスSVGというのをちょっと飛ばして、その前にSVGの描き出しの方法なんですけど、ツールによって変わってきます。イラストレーター、あとXD使ってる方、スケッチフィグマーとか使ってる方いると思うんですけど、XDスケッチフィグマーに関しては、描き出しの種類が基本的に限られているので、描き出して基本的にその中身はもう圧縮、ある程度最適化されている状態にはなっております。ただ、イラストレーターの場合はですね、何種類かSVGの保存方法があるんですけど、別名保存とスクリーン用に描き出しというのがあって、基本的にはスクリーン用に描き出しで描き出すんですけど、その後にさらに最適化することが一応できます。この他の描き出し方法であっても少しだけですけど、最適化できるんですけど、その場合はですね、するとしてこういったものがあります。ウェブのサービスもあれば、Macのアプリだったりとか、あとは何だろう、自動のビルドツールで使うようなツールもあったりします。次に、ワードプレイスで実践者SVGを使おうとするとどうするかというと、実はですね、テフォルトでは対応してなくて、SVGの画像をアップしても基本的には表示されないです。それはセキュリティの観点からテフォルトでは一応できないようになっています。なぜかというと、SVGでコードになっているので、何だろう、変なものをアップロードされるとセキュリティに関わるからです。で、それは有効化する方法があるんですけど、自分でパンクション数にちょろちょろ描くというのもあるんですけど、ただ、いろいろと面倒臭いというかプレイビーをさせようとしたら面倒臭いし、あるので、アッププラグインを使うのが悪いかなと思います。このSVGサポートというプラグインがあるんですけど、なかなか人気で他のところで使っていたんですけど、ただですね、どこかのアップデートです。ここに書いてあるように、SVGサイルにこの一行かなり挿入しないといけなくなってしまって、ちょっと手まらなという風に感じてですね、今回はこのSVGというプラグインを使いました。SVGを利用するときの注意点なんですけど、SVG自体を例えば記事のサムネイルとしてアップロードすると、自動的にそれをOGPのイメージとして利用するプラグインだったりテーマだったりがあると思うんですけど、そうなってくると表示されないです。なぜかというとOGPイメージはこのSVGに対応していないので、となるとSVGで上がった後は手動でそれ用のペングもしくはJPEGを用意してアップロードする必要があります。ちょっと手間ですけど、パフォーマンスのためにということで行いました。で、もう一つ、先ほど少し触れましたWebbyというものなんですけど、今のところ対応がですね、Edgeは対応しています。HirefoxもOK、Promeも表示するんですけど、SafariとIEは表示されないので、これを使いたかったら少しテーマというか、プラグインを使えば対応ができるんですけど、今回は詳しくは触れないです。僕の中でプラグイン自体が今1だったのが出ているところがあります。詳しく知りたい方は知られてみてください。で、次にオフスクリーン画像の知恵に読み込みという項目が出てきたので、これは何かというとですね、こういうふうにですね、画面に表示されていない画像をあらかじめダウンロードとかレンダリングする必要ないんじゃないのっていうお話なんですけど、まあ普通に考えてそうなんですけど、で、これを有効化するプラグインだったり、Jqueryのプラグインだったりとかですね、なんかいろんなツールがあるんですけど、この中でではですね、おすすめとしては、実はこれです。ローディングレイジーという特性なんです。これに関して聞いたことあるよっていう方。意外と半分くらいいらっしゃいますね。いいですね。これがですね、Chromeがそのうち、そのうちというか今もそうですね、デフォルトで対応している要は、何かプラグインとか使うんじゃなくて、ブラウザ側でもうそれをレイティブで対応しようじゃないかというお話で、今のところまだそれを対応しているのはChromeのみになっております。使い方がすごく簡単で、イメージ、イメージタグのところにローディングイコールレイジーというふうにつけるだけでですね、Chromeがそれを自動的に判断して、画面内、画面の外の画像に関してはレンダリングせず、ローディングせず入ってきたら、それをダウンロードしてレンダリングするというふうにしてくれるようになりました。で、ちょうどこの別のところでやったセッションで3カ月前にですね、Chromeが微妙な対応だったんですよ。実は主導でこの機能をオンにしないとやってくれなかったんですけど、最近になってデフォルトで本当に対応するようになりました。なので、これに関してはChromeでオーディスやると、ちゃんとそれを判断してくれて、点数として評価をしてくれるようになりました。となると、これを使うってなると他のブラウザどうするんだという話ですけど、おすすめはこのプラグインですかね。ATVレイジードードっていう、なんとGoogleさんが出しているプラグインでしてですね。ワンドプレスの画像を挿入する関数を使って画像を挿入する場合は、自動的にローディングイコールレイジというものをつけてくれるようになります。もちろんですけど、Chromeの場合はそれをつけるだけなので、一切JSとかは走らないので、それなりに速いのと、他の機体をブラウザに対しても、今のところJSによるソリューションを一応提供してくれています。ということは、これのいいところは何かというと、もしChrome以外のFirefoxとかSafariとかEdgeとか、対応するようになったらこのプラグインはそのままにしといてですね。Native対応するのみでJSはもう処理しなくていいということなんで、こういう、なんて言えばいいでしょう。プログレッシブな対応の方が個人的には好みです。で、次に、わりと王道な感じですけど、いろいろと細かいところを処理したら、結局は最終的にキャッシュをするというのは、やっぱり一番良いというか必要になってくると思います。ところで処理する場合はいろんなキャッシュプラグインがあるので、一応一旦かもしれないですよ。どれが良いというのは、実際は詳しくは紹介しないでおこうと思います。で、もう一つ、一番右の評価のところで出てきたPWAという評価があったんですけど、実はこれもパフォーマンスに少し気をする機能でございまして、PWAについて聞いたことがあるという方、あれと半分くらいですね。PWAについても詳しくは解説しませんが、このPWAの中の機能としてサービスワークというものを使っているんですけど、これはキャッシュをうまい具合コントロールして、オフラインででもサイトを見れるようにする機能なんですけど、完全にブラウザ内にキャッシュを保存するので、すごく早いというか、要は実際にインターネットと通信しなくてもいいぐらいなので、ということは対反的にはすごく早くはなります。最終的には成績化ですね。もう、成績ファイルより早いものがないので、ワードプレスを成績化しようとするのすごく大変と思うんですけど、なんとこういうサービスが実はございまして、これもコーディングなしでいけます。ちょっとお金がかかっていますけど、何かというとワードプレスを成績ファイルに完全にしてですね、ホスティングをしてくれるサービスです。というシフターというサービスが当然、なんとこれは日本の企業の公募にあるデジタル級別さま作っているサービスです。次にコードによる改善によってなってきますが、ちょっと少ないんですけど、どういったものがあるかというと、公式のテーマとかでは、もちろんやっちゃいけないことなんですけど、先ほどのコードを書かなくても進むような対策を全部やった後に、自分のテーマでもっと早くみたいなことをやりたかったら、こういうのも良いんじゃないかなというような感じです。実際の公式テーマとか、もしくは他の、何て言えばいいんでしょう。公式テーマというとはあれですけど、公式のディレクトに上がっているテーマとか、ちゃんと売られているテーマとかではあまりやらないほうがいいです。このCSSとJSの読み込みの整理がついてなんですけど、例えばですね、もうサイトによってやり方ももちろん変わってきますし、必要なページ必要じゃないページでは各地で判断する必要があるんですけど、例えばどういうものかというと、フォームやアーカイブページには、グーテンベルブのプロプトが表示していないんですが、だいたいのは表示していなかったり、さらに今回のサイトに関してはJQLですらもアーカイブページフォームには必要なかったので、もうじゃあそこでそのページで読み込む必要はないですよね、ということでですね、こういうふうに書きます。4はそのページでJQLとWP Block Libraryというグーテンベルブのこのスクリプトを読み込まないようにするという処理を行っております。ただし下に書いてあるように、このEase Adminというのが管理画面でではこの処理を外すように一応していかないと混ぜることになります。次にレンダリングを収納できるソースの除外というライトハウスが言ってくる項目があるんですけど、これは何かというとですね、JSのスクリプトを読み込むときに、このスクリプトタグというのがあるんですけど、通常入れるとこういうふうに、こういう一番上のような処理になってきます。少し解説しますが、まずHTMLが読み込む、レンダリングパース始めますよね。スクリプトタグに辿り着くとしましょう。そうなったときに、一旦HTMLのパースを停止します。その間にスクリプトのフェッチを、要するにダウンロードを行います。ダウンロードが終わった後に、この赤い部分のスクリプトの実行をそのまま行います。で、行って全部スクリプトが終わった後にHTMLパースを再開します。というふうなデコルトの処理になっております。で、今までは、こういうのがあるんで、スクリプトを下手なところに書くと、パフォーマンスに遅くなるよね、ということで、よく多分聞かれていると思うんですけど、ボディタグの、都事タグの直前にスクリプトを移しましょうという話ですね。要するにこういうことですね。HTMLパースをほとんど終わらせた後に、スクリプトのフェッチと実行しようという対策だったんですけど、もう、あんね構えからもう、我と、もう、有名になってこのアシンクとディファという属性を達とですね、この下のような実行をしてくれます。多少違いがあるので、少し解説します。アシンクの場合は、HTMLパースをしてですね、で、スクリプトに辿り着いたときに、並行して、HTMLパースをしながらスクリプトのフェッチを行なります。で、フェッチが終わった段階でですね、このスクリプトの実行に関しては必ずHTMLのパースを止めないといけないので、そこで実行して、その後終わった後にHTMLのパースを再開するような感じです。で、ディファの場合は、同じように並行してフェッチをするんですけど、終わった後にスクリプトの実行は直ちに行わずにですね、HTMLパースが全て終わった後に、全部のスクリプトの実行を行うようになっております。で、シンクとディファはどっちがいいんだろうという話なんですけど、パフォーマンスさあ的には、あまりないように感じます。そのスクリプトの位置にもよりますし、何とも言えないところ、あと、実行のスクリプトって、どのタイミングで実行してもいいというわけではないので、正直、どうなんだろうという、そのケースパイケースというところなんですが、個人的にはディファのほうが無難かなという感じはします。で、アシンクとディファが使えるようになったということでですね、今までの対策として、ボディタグの直前にスクリプトを移しましょうという対策が逆にですね、良くない手法になってきます。なぜかというと、これを見ると分かるんですけど、このスクリプトを今、ヘッダーなど頃、一番位置にあるんですけど、これは一番後ろの位置にずれるとどうなるかというと、HTMLパースが全部終わった後にスクリプトのフェッチをするで実行することになるので、全体的なかかる時間というのは実は多くなってしまうので、なので、アシンクディファとか使うのだったら、ヘッダーにも入れておいたほうが良いかなとは思います。で、実戦者ワンプレスでどういうふうに行うかというと、実はデボルトで対応しないし、プラグインもたぶんあんまりそういうのがないので、もう完全にちょっと合意にやる感じになってきます。どういうふうになっているかというと、スクリプト挿入するときに、その中の中身を正規表現で検索して、それに置き換えでのタイミングでディファをつけるというふうになっております。で、これも同様にですね、もちろんですけど、管理画面とかでやってしまうと、管理画面が動かなくなってしまうので、イザードミンで外しておくという感じにはなります。で、続きまして、もう一個、イソースヒントというちょっと難しい概念なんですけど、これは何かというと、外部のリソース、このサイト内ではなく、外部のリソースをあらかじめ、ダウンボードしておくというものになっております。いくつか、この5つの方法というか、リソースヒントをつける方法があるんですけど、それぞれの特徴がありまして、まずプリロード。これに関しては、ここに書いてあるように、ウェブフォントなど、実際に必ず必要になってくるもので、つけて加えるといいかな。例えば、ウェブフォンスとかのものに関しては、このプリロードをつけておくといいんじゃないかなという感じですね。で、プリコネクトというのは、これがですね、何て言えばいいでしょうか。概念としては少し難しいんですけど、接続だけをとりあえず早めにしておくという、モードとしてはダウンロードはしないんですけど、通信だけ先にしておくというものですね。で、DNS PreFetchというのも同じようなものでありまして、ここに書いてあるように、DNSの名前解決を行ってですね、説明を行わずに、DNSの名前解決だけを行って、プリコネクトと比べると少しはローコストになっております。さらに、ブラウザーのサポートがこっちのDNS PreFetchの方がちょっと多いです。で、DNSではないプリフetchに関しては、これはですね、ここに書いてあるこのユースケースが一番分かる、分かりやすいと思うんですけど、ページ区議のコンテンツで次のページのリソースとかですね、検索結果1位のページのリソースとか、要はこの後、ユーザーはこのコードを取るであろうというコンテンツを先に取っておくということですね。で、プリレンダーはプリフetchと似ているんですけど、これがさらにプリフetchよりも、なんとページを全部ダウンロードしておくっていう。これに関してはもう、なんだろう。上のプリフetchの方はまだ可能性が高いぐらいなんですけど、プリレンダーの場合は、もうこの後は絶対このページ行くだろうっていうぐらいのページを全体的に全部ダウンロードしておく。ただ、ここに書いてあるように、ハニーコストですね、1ページのみ指定することができて、使い方としてはログインページの、ログインした後、必ず表示するであろうページをログインページでもダウンロードしておく、っていうものとかですね。で、マートプレイスの場合はですね、できることが若干限られてくれるので、このDNSプリフetchぐらいは一応やることができます。こういうふうにですね、ちゃんとこのWPリソースヒントっていう、実はフィルターが実際にコアの方に用意されておりまして、それに対してこういうふうにですね、あらかじめプリフetchしておきたいサイトをこのように変えておくと、ちゃんとそのサイトのヘッダーのところにこれが追加されるようになっております。で、このコメントに変えてあるようにですね、WPNQスクリプトで追加した例えば、Google Formsだったり、Facebookでたくさん何かが必要だったり、Twitterで何かが必要だったりとか、そういったソースかもしくは、GiveからJQLにコメントとか、そういうのでWPNQスクリプトっていう関数で読み込んだスクリプトに関してはですね、なんと自動的に実はワークレスがこのDNSプリフetchに追加してくれますので、ということはですね、自分の行う必要がない上に、スクリプトを呼び込むときはヘッダーとか何かに直接書くんじゃなくて、こちらのこのWPNQスクリプトを使って入れることをお勧めします。あとは最終的にはもう、これですね、先ほどの性的化に言ったような感じですけど、コードをかけるなったらこういう対策もあるかなということですね。ワークレス本体としてはですね、ほとんど使わずにAPIのみを使ってですね、あとは全部自分でコードを書いて、性的ファイルとして作るっていう手法ですね。これは最近よく言われているJAMSTACKっていう手法なんですけど、実は今日のタイムペーブルも見ていただくとわかるんですけど、午後の後半にJAMSTACKについてのセッションがありますので、興味ある方はそちらに行っていただければと思います。お勧めのフレームワークとしてはNUXSTOWとか、Jatsbyはわりとワークレスと一緒に使うのはいいんじゃないかなと思っております。で、まとめに入ります。結局のパフォーマンスはなんだろうっていう話なんですけど、こういった左側のサイトがあるんですけど、一人ずつでテストで作った、本当になんだろうテキスト一行ぐらいしか、タイトル一行ぐらいしか入ってないものですと、メタデスクリプションが入ってるものなんですけど、なんとこのサイトで計測すると全てが100点なんですよ。じゃあ我々に何をしているんだっていう話なんですけど、そういうことなんですよね。結局はですね、サイトのコンテンツが増えると、パフォーマンスがもちろんですけど、さらんでいくんですよ。エントルB、総大の放送。エントルBって聞いたことある方、少ない?意外といる、みんな理系なんですかね。要するにカオスという状態がどんどん増えていくんですよ。それは世界の真理というか、コンテンツ増えていくとそうなってくるんで、じゃあどうするかというと、人の転与でそれを整理していくしかできないんです。このエントルBを減らすのは人間にしかできないらしいです。それをやろうとするとかなり地道な作業になってくるんで、パフォーマンスを上げたいってすごい簡単に言うけど、そんなに実は簡単ではないです。先ほどのサイトをパフォーマンス改善するのにどれくらいかがってくるというと、トータルで約80、90時間ぐらい変わってます。なので、10日間ぐらい実際にもちれやったということですね。で、パフォーマンス改善、先ほどの例でもあったように、何もないコンテンツが何もないサイトが一番早いということなんですけど、車の速度と空気抵抗で例えたですね。例えるとそういう感じになるんで、結局、パフォーマンスを最強にしようとしたらどうなるかというと、みんなフォーマシンになってしまう。そんなことはさすがに無理ですよね。結局は、どういうものを使いたい、どういうものを作りたいかによって、どこまでやるかになりますので、もうパフォーマンスだけみたいな感じっていうのは、おそらく全てのサイトに合うというわけではないので、要所要所に注意してやってもらえればいいと思います。ということで、以上になります。ありがとうございました。