WordPressとWeb高速化 バックエンド編 CDNの仕組み / wordpress backend web site speed trick cdn

WordPressに代表されるCMSの高速化（バックエンド編）です。
バックエンドの高速化は主にコンテンツがダウンロードされるまでの工程を速くすること。
一般的にサーバーリソースは足りているのかを見るのではなく、しっかり利用できているのかを見る必要がある。

そのためにもしっかりした計測やモニタリングが大事。

Transcript

1. WordPressの Web高速化術 （バックエンド編） バックエンド Web高速化 道玄坂 WordPress Meetup #4 〜Web表示高速化〜
2. About me 2 ABOUT ME JOB ：合同会社レッドボックス CEO Name：小川 かつひさ (KATSUHISA OGAWA） Like ：キャッシュ・負荷分散・Web高速化 https://www.facebook.com/ogawaka https://blog.redbox.ne.jp @ogawaka キャッシュ屋で 検索
3. 執筆・査読 3 ABOUT ME Software Design 2018年6月号特集 CDN［超］活用ガイド高速配信の舞台裏 「現場のプロから学ぶ SEO技術バイブル」 Web高速化セクション査読
4. Web高速化大会優勝（WordPress） 4 ABOUT ME 第3回CMSプロレス ウェブページ速度 改善「最速王者決定戦」優勝 concrete5, MovableTypeが並ぶ中、 唯一WordPressで挑んで優勝！
5. 2018 Word CampTokyo 5 ABOUT ME 2018 WordCamp Tokyo スタッフ 2018 WordCampTokyo Web高速化について登壇
6. Today’s AGENDA 6 ✓ お題： バックエンドの高速化 ✓ ターゲット： ミドルウェアやサーバーを操作できること ✓ ゴール： コストを抑えたユーザー体験の向上
7. 7 そもそもWeb高速化とは？
8. Web高速化とは 8 Webサイトの表示速度を早くすること。 13 sec 3 sec
9. 遅いWebサイト・速いWebサイトとは？ 9 遅いWeｂ 速いWeb .
10. Web高速化とは 10 Web表示速度のムラを無くすこと。
11. Web高速化とは 11 Web高速化の共通点 ユーザー体験を向上させること。
12. 12 Web高速化の項目
13. Web高速化でおこなう対策項目 13 Web高速化 対策する項目が山のようにある
14. Web高速化の種類 14 ✓ コンテンツ最適化（画像圧縮・Minify） ✓ レンダリング処理最適化 ✓ スクリプト処理最適化 ✓ ネットワーク速度 ✓ サーバースペック ✓ プロトコル（HTTP2） ✓ キャッシュ（CDN） ✓ ミドルウェア最適化（Webサーバー・DB） ✓ コンテンツ圧縮（Gzip Brotli）
15. Web高速化の主な2つの対策項目 15 1：バックエンド 2：フロントエンド コンテンツがダウンロードされた後の工程 コンテンツがダウンロードされるまでの工程 今回は こちらのお話
16. 16 バックエンドの主な対策項目
17. バックエンド対策項目 17 クライアントが、画像などのコンテンツをダウンロードするまでの工程 バックエンドの最適化 ✓ ネットワーク速度 ✓ サーバースペック ✓ プロトコル（HTTP2） ✓ キャッシュ（CDN） ✓ ミドルウェア最適化（Webサーバー・DB） ✓ コンテンツ最適化（Gzip Brotli Webp）
18. バックエンド対策項目 18 ✓とりあえずパラメーターの値を増やす 1024 → 2048
19. バックエンド対策項目 19 ✓とりあえずサーバースペック上げる
20. バックエンド対策項目 20 ✓とりあえず高速化関連プラグインを導入
21. バックエンド対策項目 21 ✓とりあえず色々インフラの仕組みを変更
22. Web高速化の種類 22 根拠がない変更はNG！ 逆に悪化することや 何かのタイミングで不具合を発生させる恐れがある。
23. 23 Web高速化は調査からはじまる。 コレをしておけばOK！という おまじないは存在しない。 Don’t guess, measure! （推測するな、計測せよ！）
24. 24 適切なモニタリングと計測
25. Web表示速度の計測 25 Google Analyticsでどのページが遅いのかを確認 行動 ↓ サイトの速度 ↓ ページ速度
26. Web表示速度の計測 26 Chrome Developer Tool
27. Web表示速度の計測 27 Google製 昔からあるやつ。昨年Light Houseエンジンを搭載 Page Speed Insight（https://www.webpagetest.org）
28. Web表示速度の計測 28 Googleが中心となって開発しているオープンソースの合成モニタリングツール WebPagetest（https://www.webpagetest.org） ・発生した通信処理の一覧 ・ウォーターフォールチャート ・一定期間毎のスクリーンショット ・プライベートインスタンスの提供 ・低速回線からのアクセス ・ブラウザやデバイス指定 ・アクセス地域の指定
29. Web表示速度の計測 29 WebPagetest（https://www.webpagetest.org）
30. どちらが問題なのか 30 問題は フロントエンドか、 それともバックエンドか
31. フロントエンドかバックエンドか 31 TTFB （Time To First Byte）が、300ms以上 OR NOT？ ※Googleが200ms以下を推奨しているためこの数値を目標とすること。 TTFBの値 平常時と遅いときの速度差 平常時との表示速度が1.5倍以上の差 OR NOT? いずれかが該当するならば バックエンド側を疑うべき。 ※アクセス元ロケーションデバイス等は同一とする
32. 32 バックエンドの調査順序
33. 33 1. サーバーのリソースが適切に利用されているか 2. 通信関連にボトルネックはないか 3. キャッシュを利用できているか 4. ミドルウェアの構成は正しいか
34. 34 サーバーリソース 編 （CPU/MEMORY/DISK IO） CPUは何パーセント消費しているのか？ではない。
35. CPU編 35 • USRが高くSYSが低いのがLinuxでは一般的。 • SYSがUSRより高いまたは同等の場合は、OSに起因する潜在的な問題の可能性が高い • IOWAITだけが高い場合はDISKの読み書き速度に問題がある可能性が高い %usr %nice %sys %iowait %irq %soft %steal %guest CPUコア毎に何パーセント使っているのか（マルチコアの場合） CPUのどの項目が利用されているか Core1 98％ Core2 5％ CPU(２Core) 片側だけしか使われていない可能性あり！
36. 36 サーバーリソース 編 （CPU/MEMORY/DISK IO） メモリーの空き容量が十分かどうか？ではない
37. Memory編 37 • SLABキャッシュが増加している場合、PHP-FPMのチューニングが必要 • SWAPを利用している場合、Memoryが足りない可能性あり ※CentOSなどの標準カーネルは、メモリーが足りていても少しだけSWAPをつかう闇仕様 MemTotal: 1012060 kB MemFree: 154340 kB Buffers: 99096 kB Cached: 323236 kB SwapCached: 0 kB Dirty: 0 kB Shmem: 600 kB Slab: 69348 kB Hugepagesize: 2048 kB メモリー使用率の種類 どのメモリー空間を利用しているのか
38. 38 サーバーリソース 編 （CPU/MEMORY/DISK IO） DISK IOはどのプロセスが占有しているか
39. DSIK IO編 39 • プロセス毎にDISKの読込み・書き込み状況が把握できる。dstat -ta --top-io-adv --top-bio-adv • 大抵はMysqlが多く利用しているケースが多い。 • PHPが読み書きを多くしている場合は、バッチ処理やプラグインの処理で重くなっている可能性が高い。 プロセス毎のI/O どのプロセスがDISK I/Oを利用しているかDSTATで確認。 ココ！！
40. 40 通信・キャッシュ 編 （DNS/キャッシュ） 見落としがちなDNS応答速度
41. DNS編 41 DNSの速度と重要性 Webサイトを訪れるユーザーは、ドメインの名前解決をDNSサーバーで行う。 この名前解決が遅いケースがある。※無料DNSを利用している場合は注意 ドメイン名を解決 www.redbox.ne.jp ⑴ DNS xxx.xxx.xxx.xxx
42. DNS編 42 DNSベンダーの速度計測サイト https://www.dnsperf.com WordPress.comが4位！
43. 43 通信・キャッシュ 編 （DNS/キャッシュ） 爆速を手に入れるためのキャッシュ
44. キャッシュ編 44 複数のキャッシュタイプ クライアント キャッシュ Webサーバー 中間 キャッシュ サーバーサイド キャッシュ ブラウザ内の キャッシュ CDNなどの 外部キャッシュ APC Memcached
45. キャッシュ編 45 クライアントキャッシュ クライアント キャッシュ ブラウザ内の キャッシュ ブラウザやアプリ内でキャッシュさせる手法。 ETAGやCache-Controlヘッダーを コンテンツのレスポンス時に追加する。 • NginxやApacheなどサーバー側 • .htaccess • PHPプログラム
46. キャッシュ編 46 サーバーサイドキャッシュ APCやMemcachedでシステム側のリソース負荷を削減 Webサーバー サーバーサイド キャッシュ APC Memcached WordPressのプラグイン Memcached Redux（リダックス） WP Memcached Manager
47. キャッシュ編 47 中間キャッシュ エッジサーバー CDNでキャッシュ配信することによって、 ある程度安定したTTFBを維持・DBなどミドルウェアに影響されないレスポンスを提供。 Webサーバー クライアント キャッシュ DNSを変更するだけでＯＫ！
48. 48 ミドルウェア構成編 （Webサーバー/データベース） パラメーターの意味をしっかり理解すること
49. ミドルウェア構成編 49 Core数＝Workerかどうか Nginxの場合、Core数に応じたWorkerを立ち上げているか Core1 Core２ Worker1 worker_processes auto; Core1 Core２ Worker1 Worker2 リクエストを処理するWorkerが足りない リクエストを処理するWorkerを増やす
50. ミドルウェア構成編 50 WorkerとCoreは1対1かどうか Workerがそれぞれのコアを参照するようにしているか Core1 Core２ Worker1 Worker2 worker_cpu_affinity auto; Core1 Core２ Worker1 Worker2
51. 51 ミドルウェア構成編 （Webサーバー/データベース） 正しいチューニング・スローログの出力
52. ミドルウェア構成編 52 データベースの基本Mysql Tunerでスキャン まずはパラメーター。しっかりメモリーを利用できているかなど基本が重要 https://github.com/rackerhacker/MySQLTuner-perl
53. ミドルウェア構成編 53 MySQLTuner実行結果
54. ミドルウェア構成編 54 スロークエリーログの出力 スロークエリーログとは、SQLの実行にかかった時間のしきい値超えを保存する仕組み my.cnf [mysqld] slow_query_log=1 long_query_time=1 log_queries_not_using_indexes=1
55. 55 バックエンドの効果比率と重要性
56. バックエンドの効果比率 56 フロントエンド 6割 バックエンド 4割 フロントエンド対策の方が少し効果が高い ＞
57. バックエンドの効果比率 57 フロントだけ対策すればいいわけではない。 Why backend ?
58. 58 近年Web高速化で 求められること
59. 早くみせるフロントトリック 59 ブラウザーでWebサイトを表示した際、 スクロールせずに最初に見える範囲（ファーストビュー）を早くする。 ココ！！
60. 求められるWeb高速化のトレンド 60 Crawlerフレンドリーであること
61. Webが表示されるまでのプロセスを把握する 61 クライアントからサーバーへ HTMLをリクエスト /index.html Click! ⑴
62. Webが表示されるまでのプロセスを把握する 62 DBからHTMLコンテンツを生成 サーバーからクライアントにHTMLを配信 ⑵ ⑶
63. Webが表示されるまでのプロセスを把握する 63 ブラウザがHTMLコードを解析 HTML内に記載されたJS/CSS/画像 をサーバーへリクエスト ⑷ ⑸
64. Webが表示されるまでのプロセスを把握する 64 サーバーからクライアントにファイル配信 ブラウザレンダリング処理開始 ⑹ ⑺
65. Webが表示されるまでのプロセスを把握する 65 Webサイトが表示！！ ⑻
66. Webが表示されるまでのプロセスを把握する 66 HTMLを生成するコストが一番時間がかかり、 Web表示速度の直結する。
67. Webが表示されるまでのプロセスを把握する 67 クライアントからサーバーへ HTMLをリクエスト /index.html Click! サーバーからクライアントにHTMLを配信 初回HTMLのレスポンスが遅いと全て遅くなる。
68. 求められるWeb高速化のトレンド 68 Question クローラーはどこから訪れるのか？
69. 求められるWeb高速化のトレンド 69 Answer 日本国外（アメリカ）からやってくる。 国内のWebサイトも海外クローラー対策で CDNを導入するケースが増えている。
70. 求められるWeb高速化のトレンド 70 ✓ HTMLのダウンロード速度は、 100 〜 500 ミリ秒が理想 ✓ 1,000 ミリ秒を越えるとクローラーがクロールを諦めてしまう可 能性あり。※１ ※１2018年9月7日 Google Webmaster Central office-hours hangout クローラーに嫌われるとインデックスされず、 検索してもでてこない。
71. バックエンドの効果比率 71 バックエンドは全ての土台 バックエンドが遅い＝全てが遅くなる
72. 72 CDNを活用した Web高速化
73. ＣＤＮの仕組み 73 CDNは地理的にはなれた場所にエッジとよばれるサーバーを設置。 ユーザーのアクセス元を判別しネットワーク的に最も近い場所から コンテンツを配信するしくみ。 多数のエッジサーバー
74. ＣＤＮの仕組み 74 ネットワーク的な距離とは？ 目的のサーバーに到達するまでに経由するルーターの数（HOP数）が 少ない方がネットワーク的に距離が最短ということ。※１ 東京リージョン CDN 東京都内から アクセス CDNが誘導 上の経路がネットワーク的に最短・高速！ ルーター ルーター ルーター ルーター ※１実際はHOP数以外にもレイテンシなど様々な内容が考慮される
75. ＣＤＮの開始方法 75 【DNSレコード】 www.redbox.ne.jp A 111.222.333.444 www.redbox.ne.jp 111.222.333.444 クライアントは 直接Webサーバーに アクセス CDN適用前 Webサーバー
76. ＣＤＮの開始方法 76 【DNSレコード】 www.redbox.ne.jp CNAME redbox.cdnw.net CDNのサブドメインに CNAMEレコード設定する CDN経由で Webサーバーにアクセス CDN適用後 エッジサーバー （CDN） Webサーバー
77. ＣＤＮの仕組み 77 初回コンテンツ取得 サーバーへ アクセスがこない キャッシュ前 キャッシュ後 初回リクエスト コンテンツをコピー CDNにコピーされた コンテンツを配信 コンテンツ 最適化 通信最適化
78. CDNの効果 78 共有回線・共有サーバーを利用している場合、時間帯によって、 サーバーリソース・回線の遅延が発生する可能性がある。 DBなどのミドルウェアに影響されないTTFBを維持し、 最短経路を通ってコンテンツを配信するため早い表示速度を保つ事ができる。 CDNで表示速度の安定化 最適化前 最適化後
79. CDNの効果 79
80. CDNの効果 80 CDNは、DNS変更だけで 手軽にWeb表示速度を向上させることが できる
81. まとめ 81 まとめ バックエンド高速化まとめ ✓ Web高速化は正しい継続的な測定からスタートすること ✓ 正しい理解の元、シンプルなバックエンドを構築 ✓ バックエンドのリソースは枯渇していないかではない 正しいリソースの使い方をしているのかどうか ✓ バックエンドはコンテンツを無加工で対策することができる。 ✓ CDNはコンテンツを加工することなく対策が可能 ✓ CDNは低スペックなWebサーバーも高スペックに変化させる ✓ クローラー対策でCDNを利用するケースが近年のトレンド
82. 82 Web高速化 質疑応答 www.facebook.com/ogawaka @ogawaka SNSでもフォロー 質問受付中！
83. THANKS!