今回のセッションは、CDNを活用したウェブ高速化術とマスチテバース時代におけるウェブ速度の重要性、ということで、小川徳久様にご答えいただいております。小川さんは、合同会社レッドブックスの代表として、10年以上経つされたパックインの技術で貸した総合的なウェブ高速フィンクを得意とされているということで、すごい盛りだくさんですね。CDNをサービスを広めるために各種登壇シピスカップを行っていらっしゃいます。そしてこのセッションでは、そもそもなぜウェブ表示が速度が重要化されているのか、優秀速度を挙げるために抑えていく、僕、べきチューニングをご話し、手順、ポイントを配置するともに、近年急遅いに普及しているCDNサービスを活用した具体的なウェブ高速化術についてご紹介いただけるということです。皆さん、お期待ください。それでは、そもそも始めようと思うんですが、準備よろしいでしょうか?はい。それでは、よろしくお願いいたします。皆様、お集まりいただきありがとうございます。今回、ウェブ高速化という事で、70スライドオールあるんですけれども、駆け足で行きたいと思います。はい。ウェブ高速化の重要性ということですね。ちょっと私の事故紹介だけさせてください。私、小川克一さんと申しまして、ゴード会社レッドボックスの代表しております。深村さんとか、ウェブ高速化というのをメインにやっているんですけれども、ブログもやってまして、キャッシュヤブログというので、キャッシュヤで検索していただくと出てくると思います。はい。で、あと本とかを少し出していたりとかで砂毒をしたりというのをしていたりですね。あと、今年にCMSプロレスという大会があってですね、いろんなCMSで最速を決定するみたいなのがあったんですけれども、ワードプレイスでイロンで優勝をいたしました。はい。すいません。はい。今日のアレンダです。ざっくり言うと3つなんですけれども、まだウェブ高速化って何でするのかということですね。あとは成功するウェブ高速化ってどういうものなのかというところと、あとはウェブ高速化のスパイスということで、この辺をサイトを置けばいいんじゃないかなというところをご案内する予定です。で、決定しました。で、ウェブの世界がまずどう変化して何が求められているのかというところですね。まずですね、デバイスネットワークの高くかということで、いろんなデバイスからアクセスがくるようになって、いろんなその改善からアクセスがくるように変化しています。なので今はほとんどスマホとかタグレットでアクセスする人が多いということで、ラインさんがちょうどスマホの利用者が8割ぐらいでPCを超えてますようみたいな発表をしております。で、次にですね、コンテンツの変化というのがありまして、テキストから画像とかになってVRになるみたいなですね、ウェブページが読み込む速度というのを、すみません、ウェブページが読み込むコンテンツサイズというのを増加し続けているというような状況ですね。で、これシスコさんが発表したものなんですけれども、2016年の約7倍ぐらいに2021年になりますようみたいなものになります。ものすごい数ですよね。で、これはですね、転送量、つまりそのネットワークトラフィックの転送量がもう右肩あがりで47%増加するみたいなのも出ていると。なのでモバイルからのアクセスはどんどん増加していって、トラフィックも多くなってくるよと。じゃあ何なのかというとですね、やっぱりその低速不安定な回線から低いスペックのデバイスを使ってですね、リッチコンテンツを高速に表示することというのが求められているんですね。なんかかなり過酷な話だと思います。PCでいい回線を使っていればそこそこ早いんですけれども、モバイルの不安定な回線からでも早くしなければいけないというところになります。はい。で、2018年ですね、ウェブ高速化の年だというふうに私感じてまして、なぜかというと一番大きいのがですね、このGoogleのスピードアップデートというのが7月から開催しました。で、ちなみにこれご存知ですよみたいな方はどのくらいらっしゃいます?あ、けっこういらっしゃいますね。ありがとうございます。そうなんです。このスピードアップデート何かというとですね、今まで検索のSUのランキングで、前までスピードというのは反映してたんですけれども、モバイルアクセスの読み込み速度というのが反映するようになりましたよというものですね。従来まではディスクトップ向けも、モバイル向けもディスクトップ向けのページの表示速度で見ていたので、ディスクトップ向けだけ高速化しておけばOKという状況になりました。で、このスピードアップデート5はですね、分かります。つまりディスクトップは今までどおりでいいんですけれども、モバイル向けの検索というのはモバイルのスピードが重要にされますよということになります。なので、今までよりやはりモバイルの表示速度というのが重要になってくるんじゃないかなというふうに考えています。で、一応Googleさんの発表によると、このユーザーが本当に遅い体験を提供しているようなページについてのみ影響をします。ただし、それはお伝え用意で段階的に提供されるみたいなことがアナウンスされています。で、とりあえず今、早いからいいかなって思っている方、例えば、共合のウェブサイトとか、同じようなウェブサイトはウェブ高速化をしてしまうとですね、対策をしていないページというのはやっぱり遅くなってしまうので、段階的に適用される可能性が高くなるということが考えられます。で、ウェブ速度が遅いと、どんなことが起こるのかというとですね、これもGoogleさんが発表していて、遅いウェブサイトを見られませんよみたいなのをですね、公表しております。今、2018年のお話だったんですけれども、少し遡れまして1994年にですね、実はこんなサイトがありました。これamazon.comのサイトですね、見てわかるとおり画像がほぼないみたいな感じですね。で、これなぜ画像がないのかというとですね、画像読み込み速度遅くなるので、テキストにしましょうということで、いない表示速度をこの1995年からamazonを意識していたというエピソードがあります。つまり、2018年確かにウェブ表示速度って重要なんですけれども、これ今も昔もウェブ表示速度って早いに越したことはないというのは変わらないんですね。はい。で、次はですね、どういうサイトが実際遅くって、どういうサイトが早いのかみたいなところ、ちょっと動画をですね、動画を準備いたしました。おそういうウェブサイトと早いウェブサイトの違いですね。まずおそういうウェブサイトから再生しております。これ大体3秒ぐらいから少し表示されてきて10秒ぐらいかってるんですね。で、じゃあ早いウェブサイトはどんなものなのかというとですね、こんな感じです。4秒。はい。なので半分以下ぐらいになってる。それがおそういうウェブサイトと、早いウェブサイトの違いですね。で、じゃあやっぱりおそういうウェブサイトじゃなくて、早いウェブサイトを目指していこうということで、実際皆さんいろんな対策されると思います。で、私、ウェブ高速化って今まで、この年度で100件ぐらいコンサルティングしてるんですけれども、そのうち70%ぐらいが結構失敗してるんですね。なのでどうしたら成功するのか、どうしたら70%の失敗を削減できるのか、みたいなことを少し一例でご紹介したいと思います。はい。100件以上担当してるんですけれども、70%ウェブ担当者は失敗していると思う。で、じゃあなぜ高速化に失敗すると思いますか。これですね、70%の方は実は経験や思い込みによる推測があります。どういうことかというとですね、例えばサーバーエンジニアとかデータベースエンジニアとか、いろんなエンジニアいらっしゃいますよね。で、それぞれの経験のもとをスペック上げましょうとか、テーブルを見直しましょうとか、JSコードを見直してみましょうとか、いろいろやるわけですよ。で、皆さんこれ言ってるほど正しいような気がしますよね。で、それぞれの生息した遅いポイントっていうのを対策します。そうすると、メモリ触れましたとか、DV速くなりましたとかって言って、みんなこう、なんかいい感じになりましたねっていう風になるんですけれども、これ実は担当者が見たい情報だけを見ている可能性があると思う。で、ウェブ担当者買って、その何かを対策して、改善確認をして、繰り返しになるんですけれども、この123ですね、つまり経験や思い込みによる推測をして、生息した遅いポイントを対策して、みたいに情報だけ見ると。で、そうすると、この繰り返しでは要産とか交済とかがなくなってしまって、あ、ウェブ高速化失敗しましたみたいな、デレバーすごく多いです。で、そのウェブサイト本当に早くなったんですかっていうのを、もう一度しっかり確認する必要はあるんですね。で、なぜそんなことが現場で起きているのかっていうとですね、実はウェブ高速化のポイントって、もうご存じかもしれないんですけど、山のようにあるんですよ。で、少しいくつかキックアップをしてきました。まず、バックエンド、これはサーバー側の高速化の中でよく使われるんですけれども、ネットワークとかサーバーのスレックとか、プロトコルとか、CDNとか、ミドルウェアの最適化とかするところですね。で、次にフロントエンドの最適化っていうところで、実際そのコンテンツをダウンロードした後にブラウザー化で処理するっていうのが入ります。で、コンテンツの最適化とかレンダリングとかスクリプトの処理とかネットワーク処理とかっていう感じで、大きくこんだけあるんですね。で、じゃあ、我々こんなにあるのに、どこを始めにやったらいいのか分からないですよね。で、なので重要なことこれはですね、推測するな、計測性をというところで、開発のされてる方はちょっと有名な文法なのかもしれないんですけれども、ウェブ表示速度って、まず調査から始まるっていうのは大変で、なのでこれをしておけばOKとかっていうですね、これをしておいたら早くなりますみたいなのをググってやるっていうのはそもそもあまりないですということをまずお伝えしたいです。で、じゃあなぜ、どのようにウェブをウィークポイントを見つけるかっていうと、一応、計測するツールが何個かありまして、今回の2つご紹介したいと思います。で、一つはこれ、Googleさんが確か去年ぐらいに、あ、今年ぐらいですかね、去年か今年ぐらいに発表したモバイルページ速度っていうのを計測する、テスト前サイトっていうのがあるんですけれども、こちらで計測するとですね、こんな感じで3秒で、これはいいですね、みたいなのが簡単に出てくるものがあります。で、もう一つはですね、ウェブページテストっていうのがありまして、これ結構昔からあるんですけれども、我々のそのウェブ高速化している業界では一番有名で、一番使われているものになります。で、何ができるかっていうと、すごいさまざまなことができるんですね。例えば、アメリカからアクセスした時にどうなのかとか、ユーザエジェントはこれにした時にどうなのかというのがですね、計測できるようになっています。で、一応右上の方にAとかBとかってスコアが出るようになってるんですけれども、ブラウザが読み込んだ順番とか、フロントのレンダリングどこを処理しているのかとか、どこに時間がかかってるのかみたいなところがですね、かなり細かく出ます。なので、こういったですね、ウェブをスキャンしてしっかりモニタイムするっていうことですね。で、担当者の経験だけで推測してどんどんやってしまわないっていうところが、もう当たり前のことかもしれないんですけど、結構現場では怒り得ているので、まず計測をして適正さのモニタリングでフロントバックエンドを適正さに高速化していきましょう。というのが70%削減できることかなというふうに思います。で、次はですね、効果が高い3つの高速カトリックみたいのを少しご案内したいと思います。で、このウェブが表示されるまでの工程、とにかく削減最適化するっていうことをこれにつけるんですね。はい、皆さん、ウェブが表示される工程ってご存知ですか?例えば、こういうボタンをポチリました。ウェブが表示されます。でも、ポチったら表示されるっていう、検索したら表示されるっていうのが普通なんですけれども、実は何回かやりとりしているんですね。で、まずクライアントからサーバーHTMLをイクエストするんですね。で、次、DBからHTMLコンテンツ生成して、ワードクレースの場合DBを生成しまして、で、クライアントにHTMLを配信します。で、ブラウザーがそのHTMLコードを解析してJSとかCSSとか足りませんねっていうのも解釈してですね。その後にサーバーの方にリクエストをして、クライアントにファイルを配信すると、全部のファイルが整ったらレンダリング開始して、やっとウェブが表示されるみたいな、実に8工程ぐらいあるんですね。で、この工程の中で最適化、削減っていうのを行っていただくのが効果的です。で、一つ目は通信プロトコロの最適化っていうことで、まずはクライアントからウェブサーバーまでさまざまな通信あると思うんですけれども、そこを最適化するっていうところですね。で、ここちょっと技術的なところになってくるんですけれども、まだのTCPの通信の最適化っていうのは結構重要です。で、これ何かっていうとですね、サーバーとクライアントが通信して、いいですよねっていう決まり事をするっていうのはあってですね。3回やると言うといいですよ、いいですか、いいですよみたいなことを3回やります。で、その3回やるっていう通信コード結構やっぱりかかってですね、これが終わらないと、HTMLが配信できないんですね。なので、画像とかのリクエストがいかないと、もう一番初めのフェーズになります。で、ここどうやってチューニングするのかっていうと、クライアントとウェブサーバーの通信になるんですけれども、あとはそのOSの中にカーネルって呼ばれているところをチューニングすると。で、Keeper LiveとかTCP Fast Openとかですね、TCP Slow Startとかっていうのがキーワードになるんですけれども、こういったカーネルのチューニングをすることによって、ドジャクスとかが来たときにスムーズにこのハンドシェイクができるというものがあります。で、次はですね、これも通信の後なんですけれども、プロトコロの最適化っていうのがありますね。まあ、皆さんもACTPSとかにしていらっしゃって、ACTPS2にした方がいいみたいなので、されてる方も多分いらっしゃるのかなと思うんですけれども、HTTP2にするっていうことはですね、プロトコロの最適化になりますね。詳しくは時間の関係でお話しできないんですけれども、HTTP1.1って昔の場合だとレンダリングブロックしたりですとかね、リクエストしたときにリクエストブロッキングしたりとかってことがあるんですけれども、2になると並列でリクエストができますので、レスポンスも並列でされるというものになります。HTTP2というのが、ACTPSが必須、一応必須になります。1.1でもできるんですけれども、今のブラウザの使用ではACTPS、SSLが必須になるので、SSLのネオシエーションみたいなチューニングもですね、かなり効いてくるんですね。OCSPとかSSLセンションキャッシュとか、サイファースイートっていうSSLが暗号化、何使うのかみたいなところを設定する必要あります。これはどこで設定するかというと、こちらのが多分馴染みがあれなのかなと思うんですけれども、アバッチとかエンジェンクスとか、そういったウェブサーバーのSSLの設定のところですね。ここでオプションを設定してあげるということになります。通信がした後に今度SSLのネオシエーションが走って、やっとコンテンツがゲットできるというところになりますね。次はコンテンツサイズの受賞とかになります。今、実はウェブサイトの中で6割ぐらいが画像コンテンツなんですよ。私は1万サイトくらいクロールして、ちょっと確認してみたところ大体6割ぐらい画像になってます。画像もちろん縮小したりするというのが必要なんですけれども、まずCSSとかJSとかHTMLのミニファイっていうのが結構聞いてきます。ミニファイ何かというと、余分なスペースとか、いらない文字とか、削って、開業とかですね、一行にするみたいなのがあります。これをすると、平均で大体15%ぐらいコンテンツが圧縮されます。ですので、ライブラリを使ってあらかじめ圧縮しておくということは結構、ウェブ表示速度には直結してくると。先ほどの画像サイズですね。特にPC用の大きい画像をモバイル用に配信している方っていうのはもうすごくいらっしゃいます。実際画面なのに大きい画像を表示しているんですね。なので、モバイル用にまずしっかりリサイズするということ。あとは、ChromeとかAndroid限定になってしまうんですけれども、ウェピっていうGoogleが作ったフォーマットがございまして、かなり圧縮できるフォーマットがあります。そちらに変換していただくとか、ロースデースをしていただくとか、あとはリサイズですね、先ほどのようにしていただくっていうのが、画像サイズの縮小のポイントかなと思います。今、コンテンツサイズの縮小、物理的に画像とかCSSとかを縮小しますって話だったんですけれども、今度ちょっとサーバーサイドのお話になって、コンテンツを圧縮するみたいなこともやっぱり重要になります。G-Zipで圧縮するって大体みなさんされているとは思うんですけれども、テキストベースのHTMLとかのテキストベースの物を十分の1にして、クライアントに圧縮をして配信するというG-Zipですね。これは先ほどの同じでウェブサーバーの方で設定をします。で、ちょっと一つご紹介したいのが、今までG-Zipで圧縮するっても、かなり昔からされているというか、そういう技術なんですけれども、最近Grotryという新しい圧縮技術がありまして、これはですね、G-Zipのと比べて大体15%とか20%ぐらいさらに圧縮できるみたいな企画になります。で、今対応しているのは一応アパッチもNGXも対応しているんですけれども、Grotryというモジュールを入れてコンパイルしなければいけないと、ちょっと指揮が高いんですね。で、さらにクロームだった時はGrotryで圧縮する。そうじゃなかった時はG-Zipにするみたいなのをちょっと分けなきゃいけないので、ちょっとテクニックあるな部分が入ってきます。ただ、G-Zipよりもかなり圧縮できるので、大手のウェブサイトとかはクロームとかでアクセスすると、このGrotryで圧縮されているなというのが分かります。で、2番目がこういったコンテンツの縮小になるんですけれども、3つ目、これはですね、表示速度の安定化ということで、常に一定のおよび表示速度である必要はあります。これ、なんでだか分かりますか?例えば、私が今ここでアクセスして、あ、早い早い、それで満足したいけないということなんですね。例えば、ある通信の時、ある時間帯にウェブが遅いとですね、もうそれは遅いウェブサイトって認識されてしまうんですね。なので、常にどんな時間でも同じくらいのスピードにするということが、ウェブ高速があって結構重要なんです。じゃあ、どうやって表示速度の安定化をするのかというと、一番手軽なのはキャッシュを導入するということですね。CDNっていうのを導入すると、CDNでキャッシュをして配信しますので、ちょっとウェブサーバーとクライアントの間にCDNが入るみたいな感じになります。キャッシュされたコンテンツというのは、大容量の回線から配信されますので、常に一定のレスポンスで配信されるという効果があります。ウェブサーバーって結構共有サーバー使っていたりとか、回線も共有だったりするので、正直、お昼時なんか遅いということが気づかないけど、あるんですね。そういったところをCDNで配信して安定したレスポンスにしましょうみたいなのが結構効果的です。その他のトリック、何個かあるんですけれども、レジロードとか、サービスワーカーを使ったりとか、プリレンダリングとか、あと、HTPのサーバープッシュって言って、通常の画像くださいってリクエストをして、初めて画像がレスポンスされるんですけれども、このHTPのサーバープッシュを使うとリクエストをしないで、サーバーのほうからハイバードですっていうふうに渡してくれるんですね。っていうのは技術があるんですけれども、もしご興味がある方はちょっとググって見てください。この辺もかなりですね、高速カトリックで聴いてくるものになります。次ですね、今回ちょっとワードキャンプっていうことで、ワードプレイスで単体でできる高速カーって、ちょっと1個だけご紹介したいなと思います。先ほど私3つポイントがありますよってお話したんですけれども、その中でワードプレイスだけでできることは何なのかなって思ったら、コンテンツサイズの縮小とか圧縮なんじゃないかなって思いました。コンテンツの圧縮とかっていろんなプラグイン出てると思うんですね。画像をこれ使ってますとか、様々なプラグインあるんですけれども、なるべくその他の環境とか感傷しないというか、プラグインをちょっと見つけてきて1個だけご紹介します。これライトスピードキャッシュってやつなんですけれども、先ほどのようにミニファインみたいなのもできますし、画像もウェッピンしたりとか圧縮したりすることができます。先ほどのHTTPのサーバープッシュっていう機能ですね、これを使うのにサーバーがいろいろ設定しなければいけないんですけれども、それもライトスピードキャッシュは唯一対応していたので、かなり優秀なんじゃないかなというふうに思ってます。次、CDNを活用したウェブ高速化についてですね、ちなみに皆さんCDNご存知ですみたいな方どのくらいいらっしゃいますか?すごいいらっしゃいますね。こんなにいらっしゃるんですか?すごいですね。私は3年前にCDNどのくらい使ってますか?2人くらいしかって言い訳なくてですね、本当にCDNって結構流行っていて、昔大手しか使わないみたいな感じだったんですけれども、どんな規模のウェブでも大体CDN入ってるという状況なんですね。ちょっとCDNの宿命について簡単にご紹介したいなと思います。CDNってコンテンツ、コンテンツデリバリネットワークという意味で、ネットワークなんですね。で、多数のエッジサーバーっていうのがいろんなところに配置されてます。ネットワーク的に最も近い場所からコンテンツを配信するっていう仕組みになります。このネットワーク的に最も近いっていうのは結構重要でですね、ちょっと簡単な図を用意しました。これです。まず物理的に近いっていうのは何となくわかりますよね。例えば東京から北海道までと東京から大阪まで、どっちが近いのかみたいな大阪ですよね。ただその同じ、例えば東京から東京だったとしても、サーバーに到達するまでのにですね、ルーターっていうものをどんどん追加の経由をして、サーバーに到達してるんですけれども、経由するルーターが少ない方が早いんですね。これ、上と下の経由を見ると、下の方がルーターがたくさんあって、上の方はルーターが少ないですよね。なので、こっちの上の方のルーターが最短だよっていうのをCGNが教えてくれるんですね。なので、ユーザーはアクセスするときに、特に何か早い経路とかっていうのを選択しなくて自動で、一番最適な経路でウェブサワーに到達するというのが、CGNのネットワーク的な仕組みになります。CGNっていくつか種類があるんですけれども、まずは一般的なCGNでどうやって設定するのかみたいなところも少しご紹介したいと思います。まずは、CGNはですね、DNSレコードが変更して設定をするんですね。これは、CGN的用前、大体ウェブサイトのドメイイメイをAレコードでITアドレスを設定して終わりみたいな、そんな感じだと思います。ただ、CGNを導入すればいいっていうのはちょっと違って、Aレコードを使わないんです。実は、CNMっていうレコードがありまして、このCNMを使って、CGNのサブドメイに向けるということをします。そうするとですね、例えばそのウェブサイトのドメイイメイでアクセスをしたら、CGNのサーバーに着信するようになります。で、CGNは元々のワードプレスとかが入っているウェブサイトにコンテンツを取りに行くっていう動作になります。ですので、何かコンテンツを書き換えなければいけないというわけではなくて、同じドメインを使うことができて、かつ、DNSの変更だけで元々に戻したり適用したり、一応できますよというものになります。で、このCGNができることって結構あってですね、先ほどちょっとご紹介した3つのプロトコンの最適化とか、通信の最適化とか、コンテンツの圧縮とか、表現速度を安定化しますみたいなのが丸とできちゃうんですね。で、CGNの仕組みっていうところでちょっと簡単な図をご用意しました。このCGNはですね、まずは一番上がキャッシュ前ってことで初回アクセスになります。で、真ん中はCGNで一番向かって右側がオリジンサーバーっておかれるもので、ワードプレスとかが入ってるウェブサイトです。で、クライアントが初めてアクセスするのは必ずCGNになります。で、CGNのアクセスが来たらですね、オリジナルのサーバーからコンテンツをコピーして、クライアントに配信します。そうすると、CGNの中でコンテンツキャッシュされますので、次回以降、このワードプレスのサーバーにアクセスが来なくなるんですね。なので、例えばDVの負荷が減ったりとか、ネットワークの負荷が減ったりとか、というふうに、そういった効果があります。で、このキャッシュをするときに、実はコンテンツの最適化ができるCGNが結構ありまして、例えば大きい画を取得して、その画像をモバイル、これはモバイルだというふうに判断してですね、最適なサイズにリサイズしてキャッシュをして配信するとか、あとは先程のようにロースレースをして配信するとか、ということができるようなものがあります。あとはミニファイとかも自動でやってくれたりするのもありますね。で、このクライアントとCGNの間っていうのは、通信が自動的に最適化されますので、ウェブサーバーにほぼ手を加えることがないっていうのは一番特徴かなと思います。なので、何かこう文字を入れなきゃいけないとか、サーバーの知識はないといけないっていうのがないというのがCGNの特徴かなという。次です。これ、CGNの効果ということで、共有回線とかやっぱり共有サーバーを使っていると、この最適化もあえるというのがCGNの使う前なんですけれども、結構ギザギザですよね。これ、1日の間のレスポンスを測定してみたんですけれども、遅いときすごい、10倍ぐらい遅いんですね。これはやっぱりAWSを使っているとか、VPS使っているとか、どういうところでもシェアの回線になりますので、安定って意外と難しかったりするんですね。それをCGNをやることによってギザギザがなくなるということで、結構一定のレスポンスでキークがキープできるようになります。実際じゃ、ウェブサーバーと、あとCGNを入れたときと、さらにチューニングしたときってどのくらい変わるのかっていうのをちょっと私のブログで試験していました。で、これウェブ、一番右側ですかね。右側がウェブサーバー。で、ちょっと名称違いですけどブーストって書いてあるら真ん中がCGNの適用したときです。で、一番左側がCGNをさらにカスタマイズして再適化したときの動画になります。ちょっとご覧ください。CGNを入れると7.5秒が4秒になり、さらにカスタマイズすると1.8秒になるって恐ろしいことになるんですね。ちょっともう一回再生してみましょうか。ちょっと早いですよね、これ。1.8秒。このくらい違ってくるんですね。ウェブの速さ。ですので、CGNを入れてチューニングするっていうのはかなり効果が高いということがわかりいただけたかなというふうに思います。ちょっとかけ足になってしまったんですが早いまとめです。今回はウェブ高速化っていうことで、まずGoogleのアルゴリズムというかSEO対策でウェブ高速化ってすごく重要になってきてるって思います。特にモバイルページスピードっていうのは、例えば工場することはもう必須だと思っています。ウェブの高速化って、ほんとにか正しい測定からスタートしなければ何の意味もないですよということですね。あとフロントエンドとバックエンド。フロントエンドっていうのは画像とかをダウンロードした後の処理、グラウザの中の処理ですね。JSとかそういったところになるんですけどもそういった部分とバックエンド、サーバー側とかDBとかHPとかそういったところ適切な対策が必要になりますと。ウェブ高速化はどれが一番効果が高いのかっていうとやっぱりコンテンツを圧縮していくとか通信に再適化するとか通信速度を安定化させる。やっぱりここ3つなのかな、どういうふうに考えています。ウェブ表に速度っていうのはCレールを使うことによって結構加速しました。スタンダードの技術になりつつありますよというところですね。フロントとバックエンド、それぞれ手動で再適化するのではなくてCDを入れると無加工で再適化されてしまうという感じになります。ただ、気を付けていただきたいのは魔法のツールではないので入れたらOKっていうわけではないんですね。やっぱりキャッシュするためにHPヘッダーを適切に設定するとかワードプレスであったら管理画面があると思うんですけどもWPアドミンで始まるところはキャッシュしていないようにするとかリクエストクッキーがたくさんいろんなユーザーさんついてくるのでリクエストクッキーをいらないところを削除してなるべくキャッシュするようにするとかそういったキャッシュのチューニングっていうのは必要になるんですけれどもそういったチューニングをすることによって先ほどのように1.4秒っていう値をたざき出しております。この辺りは先ほどのキャッシュブログというのが既に適用されている早いページになりますのでぜひご興味がある方はチェックしてみてください。CDNを入れると裏のウェブサーバーっていうのが隠れますので何かウェブサーバーをアップウレブしなくてもよくて結構そのテーステックな改善を使っていたとしてもCDNを入れればカワーできるということが結構ありますね。では次は質問タイムにしたいと思います。あと5分ちょっとぐらいあるみたいですので何でも結構です。ご質問がある方手を挙げていただけると持ってきます。マイクを持って行ってくれます。ここですね10分くらいあるんでお話どうもありがとうございます。私福井と申します。最近ほどこれでページの速度ベンチマークにするといいですよというサービス2つ紹介していただいたんですが私が個人的に使用しているページスピードインサイトなんですけどあれはあんまりおすすめではないんでしょうか?ページスピードインサイトでもいいんですけれどもざっくりとした内容しかわからないというのがありますね。なので簡易的に確認するのであればページスピードインサイトとかでもいいんですけれどもより組み込んでどこにボトルネックがあるのか調査するのは先ほどのウェブページテストっていうのを使っていただくのは1番かなと思っています。ありがとうございます。そちらの方も確認させていただきます。ぜひ確認してみてください。ありがとうございます。他に質問ある方いらっしゃいますか?お話ありがとうございました。ウェブページの高速化をしていくにあたってどのくらいベースラインに考えるかというのを最近悩んでいて特に最近格安のシムとかスマホが出てきてアイフを使ってどこも使っている人と副安心とかを使っている人でだいぶウェブの体験が変わっていると思うんですけどその辺ってどのくらいベースラインというかターゲットにして最適化していけばよいのかなと。なるほど。これは結構いい質問でユーザーのアクセスする回線が遅いとやっぱりどんだけ対策しても遅くはなっちゃうんですよ。ただ一応その指標みたいなのがあってウェブのファストビューって言われる初めの長いページとかはフルロードするときに何秒かかかるんですけれども初めのファストビューで3秒以下で表示されることというのが一つの目安になってましてあとTTFBという値があるんですけれどもだからTTFBに知ってますみたいな方がいらっしゃいます?でも少ないけどいらっしゃるんですね。ありがとうございます。TTFBってTime to First Wideって言って先ほどのTTFB通信をした後にHMLコンテンツ配信されるんですけどその最初の一倍とか到達するまでの時間っていうのがあるんですね。これ実はGoogleさんで200ミリセックじゃなきゃいけないみたいなのがあります。遅いウェブサーバーを使っていたりとかシェアーのウェブサーバーを使っていたりすると200ミリセック攻撃対するんですよ。それってウェブの表示速度に直結しますのでやっぱりTTFBは200ミリ以下でHPSは3秒っていうところをまず意識していただくのがよろしいかなと思います。ありがとうございます。僕の質問のちょっとずれてしまったんですけど3秒というのをどの回線速度とかどの端末で実現すればよいのかなって思ってそうですね。まずは一般的な先ほどのウェブページテストとかであればだいたい1メガぐらいの回線を使ってモバイルの有大人と使ってだいたい3秒ぐらい。それ以上遅いものというのはやはり3秒以上かかってしまうので一応そのベースとしてはだいたい平均で皆さん1メガぐらいは出ると思うので1メガBPSの回線で0.4が100とかそのくらいの値をセットして3秒ぐらい。PCの場合ですと10メガぐらいの回線をベースにだいたい1円が50ミリセックとかそのくらいで3秒とかにするとよろしいかなと思います。ありがとうございます。どうかにありますか?こちらに。すみません。ちょっと問いで持ってきます。ちょっと白と質問かは出ないんですけどもPCの使うと他のサーバーで分散できて負けらっしゃっててことなんですけど国内とか、そういうちょっと狭いエリアで導入した場合って効果っていうのはどれほど?そうですね。まず、例えばアメリカにアメリカのユーザーが日本のサーバーにアクセスするっていうのになるとすごく遅くなると思うんですね。アメリカにそのCDNがある場合は間違いなく効果があるんですけれども国内だったとしても効果はかなり期待できます。というのは、先ほどのように通信の最適化を自動でしてくれたりですとかあとはやっぱりウェブサーバーの方のコンテンツをキャッシュしますのでワードプレースで言うとデータベースの生成するコストとかDBからコンテンツを取り出すっていう作業がやっぱり一番コストがかかるんですね。そこがだいたい10倍ぐらい高速化されますので国内であっても高い効果が出ると思います。ありがとうございます。ありがとうございます。ちょっと私も素質もなってしまうかもしれないんですけどもCDNにコンテンツをキャッシュするということはオリジンサーバーでワードプレースでいろいろコンテンツを更新して例えば記事が増えていくとトップページのイチラがどんどん更新されていくと思うんですけれどもそういったものが2、3、2万円のものになってしまったりとかするのでしょうか。そうですね。まずキャッシュされますので例えばオリジンの方で更新する場合、例えばガードを更新したですとかあとページを増やしてトップページに記事1欄が出ているような状況という場合はやはり古いデータが残ったままになりますのでそのときはCDNに対してキャッシュ削除という命令をする必要があるんですね。CDNベンダーさんってだいたいワードプレースのプラグインというのがあってIDパスアドみたいに入れるともう記事を更新としたときにそのURLをキャッシュ削除しますという命令が勝手に飛ぶようになるのでそういう意図で更新されてくるようになっていますね。ただキャッシュ削除というのは必要になりますので結構難しいところなんですよね。ワードプレースとかと関連ページみたいなのがたくさんあるので結局全部キャッシュ削除しなきゃいけないみたいになってしまうんですけれども一応プラグインとかを使って更新したらキャッシュ削除してリフレッシュするという作業は必要になります。CDNのサービスを提供しているプラグイン?そうですね。あとはワードプレースとかでレストAPIとか発行できるようなプラグインとかがあれば大体API、CDNのサービスでキャッシュ削除するAPIで提供していますので同じような感じで組んでいただくかあとはご自身でモジュール作っていただいてキャッシュ削除のモジュールで実行していただくかという感じになります。配信時間を明確にしたいサービスだと結構厳しい?一応配信時間、ワードプレースだと空論とかで予約して時間を決めて記事更新するとかってあると思うんですけれども一応プラグインとかで入れれば空論の実行時間で記事をキャッシュ削除するというふうに動くことはほとんどですのでそこはあまり意識する必要はないかなと思います。ありがとうございました。はい、ありがとうございます。キャッシュ削除というのはかなり大変です。もう時間が詰まっているのでこの辺で引き上げさせていただきたいと思います。青葉さん、ありがとうございました。