レスポンシブデザイン前提のWordPressの表示速度高速化の考え方

レスポンシブデザイン前提のWordPressの表示速度高速化の考え方

1. 1. 自己紹介  株式会社Spelldata 代表取締役社長  ACM(Association for Computing Machinery)会員  CMG(Computer Measurement Group)会員  ISACA(Information Systems Audit and Control Association)会員  日本統計学会賛助会員  html5j パフォーマンス部部長  統計学を基礎から学ぶ! 中西塾主催  Webサイトパフォーマンスに関係する仕事を始めて、もう13年目  やってきた事  VMware … 日本人初のVCPトレーナー  Akamai … プロフェッショナルサービス  Verizon Business … プリンシパルコンサルタント  Keynote Systems … 日本代表  Catchpoint Systems … 日本代表
2. 2. 今日、お話する内容  現在の表示速度の基準値  「速さ」はなぜ、重要なのか?  法律での品質の瑕疵担保責任追及の変化  Web表示速度高速化の考え方  レスポンシブデザイン前提のWordPressの高速化  WordPress高速化検証  まとめ
3. 3. 現在の表示速度の基準値 速さ大好き日本人の周回遅れの状況
4. 4. 「え、表示速度? 何それ?」
5. 5. 現在の世界基準  表示開始時間 … 0.5秒以内  Webブラウザ上に最初の1ピクセル目が表示された時間  表示完了時間 … 2秒以内  DOM Complete  DOM処理が終わって、ユーザが操作可能になった時間  エラー率 … 3%未満
6. 6. え、500msですか?
7. 7. え、2秒で表示完了ですか?
8. 8. 日本のEコマースサイトのパフォーマンス Dynatrace ― https://www.dynatrace.com/en/benchmarks/view-benchmarks.html
9. 9. アメリカのEコマースサイトの パフォーマンス Dynatrace ― https://www.dynatrace.com/en/benchmarks/view-benchmarks.html
10. 10. 「速さ」はなぜ、重要なのか? ユーザが、今、最も望むこと
11. 11. 「パフォーマンスは、重要だと思うんですが、 今、他の優先事項があるんで…」
12. 12. 「遅いサイトは二度と行かない」 参照資料：Compuware（2012年）
13. 13. Webサイトに期待するもの Webサイトに期待すること 1 2 3 4 サンプ ル数 平均レート コンテンツの新しさや更新頻度 39% 400 29% 295 19% 191 13% 127 1,013 2.04 パフォーマンス （バッファリングなしで、動画再生、 ページの読み込みが速い等） 52% 523 26% 266 9% 87 14% 137 1,013 1.84 モバイルサイトとデスクトップサイト の体験が同一であること 20% 205 27% 274 35% 356 17% 177 1,012 2.50 パーソナライズされたコンテンツ 12% 117 18% 182 26% 259 44% 447 1,005 3.03 Limelight Networks http://img03.en25.com/Web/LLNW/%7Bb97f8e45-2370-4f4b-8c8e-fa4141051c72%7D_2014StateoftheUserExperience.pdf
14. 14. Webサイトを見続けてもらうチャンスは一度きり お見合いパーティー並みにシビア
15. 15. 見てもらえなければ、「他の優先事項」を 頑張っても水の泡です。
16. 16. 高速化によって、セッション数が増加 表示完了時間が6秒から3秒に半減 1日あたりのセッション数は、10,000から20,000へ倍増
17. 17. 直帰率の改善
18. 18. パフォーマンスは、最優先事項です!
19. 19. 法律での品質の瑕疵担保責任 の追及の変化 「仕様」の実現から「目的」の実現へ
20. 20. 非機能要件に対する暗黙の期待  Web制作会社さん： 「表示速度について、お客様から要求されることって、ほぼないんで すよ」  発注側の会社さん: 「え、Webサイトって、高速じゃないと駄目でしょ。当然でしょ?」
21. 21. 従来の民法の規定  第六百三十五条 仕事の目的物に瑕疵があり、そのために契約をした目的を達するこ とができないときは、注文者は、契約の解除をすることができる。 （後略）
22. 22. 民法改正に伴う請負側の責任の変化  （請負人の担保責任の制限） 第六百三十六条 請負人が種類又は品質に関して契約の内容に適合しない仕事の 目的物を注文者に引き渡したとき（中略）は、注文者は、注文者の 供した材料の性質又は注文者の与えた指図によって生じた不適合 を理由として、履行の追完の請求、報酬の減額の請求、損害賠償 の請求及び契約の解除をすることができない。ただし、請負人がそ の材料又は指図が不適当であることを知りながら告げなかったとき は、この限りでない。
23. 23. 「仕様の実現」から「目的の実現」へ  民法の条文に「品質」という言葉が入る  従来の瑕疵担保責任 … 発注者側が指示した「仕様」を実現している かどうか  新しい民法での瑕疵担保責任 … 発注者側が意図している「目的」を 実現しているかどうか  非機能要件に対する責任が、これからは契約上入っていなくても、 自動的に責任を負う
24. 24. Web表示速度高速化の考え方 パフォーマンス管理は品質管理 品質管理は、統計的手法が大事
25. 25. Best Practiceから Proven Practiceへ http://www.oreilly.com/webops-perf/free/files/effective-performance-engineering.pdf
26. 26. Google PageSpeed Insight マーケット教育用
27. 27. 表示開始時間0.5秒になりましたか? 表示完了時間2秒になりましたか?
28. 28. 「ベストプラクティス」とは何か? 問題の事象 解決策 解決
29. 29. 「ベストプラクティス」? ベストプラクティス 問題の 事象 解決策 解決 問題の 事象 解決策 解決 問題の 事象 解決策 解決 問題の 事象 解決策 解決 問題の 事象 解決策 解決 問題の 事象 解決策 解決
30. 30. 事象の背後にある原因が違うと、解決策は 変わる 解決策B 解決原因B 原因A 原因C 解決策C 解決策A 問題の 事象
31. 31. 事象例：画像が重い  計測してみたら、画像が重いと出た  ベストプラクティス： 画像を軽量化しなさい→速くならない  過去の事例  Windowsのサーバを使っており、NTFSでフォーマットされたディスクパーティ ションを80%以上使っていた  NFSでNASをマウントして使っていた  HTMLの生成と、画像の配信を同じディスク上で行って、ディスクのアクセス 競合が発生していた  __d_lookup関数がCPUを使いまくる
32. 32. 大量の画像やらCSSやらJavaScriptを 配信すると…
33. 33. Webの配信システムは複雑系 34 可用性 ユーザや顧客は、自社サイト に到達できるのか? ユーザや顧客は自社サイト に登録やログインできるのか ? 自社サイトに、主要マーケッ トの地域から到達できるのか ? 表示速度 ユーザや顧客は、自社サイト の表示速度に満足している のか? サードパーティのタグのレス ポンス速度に問題はないか? サイトの更新やアップグレー ドは、問題を引き起こしてい ないか? DNSCDN ADS ISP ソーシャ ル ネットワー ク データ ベース コード ブラウザ レイテンシ ルーティン グ ピア接続 ハードウェ ア クラウド
34. 34. Chromeの開発者ツールではダメなの?
35. 35. カバー率（経路）の問題
36. 36. カバー率（時間）の問題
37. 37. その速さ どこまで、いつまで保証できますか？
38. 38. パフォーマンスの数値は一意に定まらない
39. 39. 平均の罠 1秒 2秒 3秒 4秒 5秒 6秒 7秒
40. 40. ラプラスの魔 もしも、ある瞬間における全ての物質 の力学的状態と力を知ることができ、 かつ、もしも、それらのデータを解析で きるだけの能力の知性が存在するとす れば、この知性にとっては、不確実な ことは何もなくなり、その目には未来も （過去同様に）全て見えているであろう。 — 『確率の解析的理論』1812年
41. 41. 真の値には、 確率的に近づいていくしかない
42. 42. 病気の治療は、診察が大事 品質は、計測と分析が大事
43. 43. 治療＝改善作業
44. 44. エンジニアは「医師」であるべき
45. 45. データに基づく分析をしましょう!
46. 46. レスポンシブデザイン前提の WordPressの高速化 Weakest linkを考える
47. 47. 表示速度改善手法 ベストプラクティス系  「Webの表示速度を高速化する10の手法」 部分最適化系  ハードディスクをSSDにしよう！  JavaScriptを高速化しよう！  「非同期処理」  PHP高速化  MySQL高速化  キャッシュ  画像圧縮  CDNの導入
48. 48. Weakest Linkという考え  “A chain is only as strong as its weakest link.”  Webサイト配信においては、ネットワークが一番「弱い」
49. 49. 「ムーアの法則」に従って拡大しているイン ターネット網 http://iopscience.iop.org/1367-2630/10/12/123027/fulltext/ AS(autonomous system)レベルでのノード数の増加
50. 50. インターネット網は今後、 ますます混雑していく
51. 51. 携帯網は、時間単位での配信容量が 物理的に増やせない ― 観覧車と同じ London Eye ― 定員25人
52. 52. 1ページあたり200KBを超えたら、 LTEでは物理的に3秒以内の配信はできない
53. 53. 熊本市 ― スマートフォンサイト
54. 54. ページ容量 … 162KB
55. 55. ウォーターフォール図
56. 56. Yahoo! Japan ― スマートフォンサイト
57. 57. ページ容量 ― 434KB
58. 58. ウォーターフォール図 接続エラーが発生すると、足を引っ張る
59. 59. Spelldata ― スマートフォンサイト
60. 60. ページ容量 ― 318KB
61. 61. ウォーターフォール図
62. 62. WordPress高速化比較検証
63. 63. 何もしていないWordPressサイトと 高速化されたWordPressサイトの比較 高速化したWordPress 素の状態のWordPress
64. 64. 高 速 化 さ れ た WordPressVanillaWordPress
65. 65. WordPressのホストのみの配信データ
66. 66. WordPressのPHP処理（HTML生成）のみの 比較
67. 67. WordPressを高速化しても ネットワークは高速化できない
68. 68. 画像、CSS、JavaScriptなどの詰め込み過ぎ が、WordPressの高速化を殺す
69. 69. 高速化の考え方のパラダイムシフト  「どこまで高速化するか」から「どこまで遅延を許せるか」へ  3秒以内に配信し切るための容量制限  3G通信 … 100KB  LTE … 200KB  容量上の制限が、物理法則上定まっているため、携帯網経由でス マートフォンサイトを表示させるには、この容量以下にしなければい けない  Webサイトを構築するときの、会話が変わる  「200KBを超えると、絶対、3秒以内の表示は出来ないです。それでも、この 画像を入れますか?」
70. 70. Third-partyコンテンツとの付き合い方  現在の遅延の主たる原因は、Third-partyコンテンツにある  Google Analytics  広告配信  効果測定  SNS  きちんと計測して、遅延が見られた場合には対処が必要  Third-partyと高速化について交渉する  外す  代替サービスに変える  ビジネスモデルを見直す
71. 71. まとめ  表示速度は、今や、表示開始0.5秒、表示完了2秒が世界標準です。  表示速度の高速化は、お仕事ですから、きちんと保証できるように しましょう。  保証するためには、計測しないといけません。  きちんと改善するためにはデータに基づいた分析が必要です。  200KBを超えると、LTE網で3秒以内に配信しきれません。
72. 72. Q&A