O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
自己紹介  株式会社Spelldata 代表取締役社長  ACM(Association for Computing Machinery)会員  CMG(Computer Measurement Group)会員  ISACA(Info...
今日、お話する内容  現在の表示速度の基準値  「速さ」はなぜ、重要なのか?  法律での品質の瑕疵担保責任追及の変化  Web表示速度高速化の考え方  レスポンシブデザイン前提のWordPressの高速化  WordPress高速化...
現在の表示速度の基準値 速さ大好き日本人の周回遅れの状況
「え、表示速度? 何それ?」
現在の世界基準  表示開始時間 … 0.5秒以内  Webブラウザ上に最初の1ピクセル目が表示された時間  表示完了時間 … 2秒以内  DOM Complete  DOM処理が終わって、ユーザが操作可能になった時間  エラー率 …...
え、500msですか?
え、2秒で表示完了ですか?
日本のEコマースサイトのパフォーマンス Dynatrace ― https://www.dynatrace.com/en/benchmarks/view-benchmarks.html
アメリカのEコマースサイトの パフォーマンス Dynatrace ― https://www.dynatrace.com/en/benchmarks/view-benchmarks.html
「速さ」はなぜ、重要なのか? ユーザが、今、最も望むこと
「パフォーマンスは、重要だと思うんですが、 今、他の優先事項があるんで…」
「遅いサイトは二度と行かない」 参照資料：Compuware（2012年）
Webサイトに期待するもの Webサイトに期待すること 1 2 3 4 サンプ ル数 平均レート コンテンツの新しさや更新頻度 39% 400 29% 295 19% 191 13% 127 1,013 2.04 パフォーマンス （バッファリン...
Webサイトを見続けてもらうチャンスは一度きり お見合いパーティー並みにシビア
見てもらえなければ、「他の優先事項」を 頑張っても水の泡です。
高速化によって、セッション数が増加 表示完了時間が6秒から3秒に半減 1日あたりのセッション数は、10,000から20,000へ倍増
直帰率の改善
パフォーマンスは、最優先事項です!
法律での品質の瑕疵担保責任 の追及の変化 「仕様」の実現から「目的」の実現へ
非機能要件に対する暗黙の期待  Web制作会社さん： 「表示速度について、お客様から要求されることって、ほぼないんで すよ」  発注側の会社さん: 「え、Webサイトって、高速じゃないと駄目でしょ。当然でしょ?」
従来の民法の規定  第六百三十五条 仕事の目的物に瑕疵があり、そのために契約をした目的を達するこ とができないときは、注文者は、契約の解除をすることができる。 （後略）
民法改正に伴う請負側の責任の変化  （請負人の担保責任の制限） 第六百三十六条 請負人が種類又は品質に関して契約の内容に適合しない仕事の 目的物を注文者に引き渡したとき（中略）は、注文者は、注文者の 供した材料の性質又は注文者の与えた指図によ...
「仕様の実現」から「目的の実現」へ  民法の条文に「品質」という言葉が入る  従来の瑕疵担保責任 … 発注者側が指示した「仕様」を実現している かどうか  新しい民法での瑕疵担保責任 … 発注者側が意図している「目的」を 実現しているかど...
Web表示速度高速化の考え方 パフォーマンス管理は品質管理 品質管理は、統計的手法が大事
Best Practiceから Proven Practiceへ http://www.oreilly.com/webops-perf/free/files/effective-performance-engineering.pdf
Google PageSpeed Insight マーケット教育用
表示開始時間0.5秒になりましたか? 表示完了時間2秒になりましたか?
「ベストプラクティス」とは何か? 問題の事象 解決策 解決
「ベストプラクティス」? ベストプラクティス 問題の 事象 解決策 解決 問題の 事象 解決策 解決 問題の 事象 解決策 解決 問題の 事象 解決策 解決 問題の 事象 解決策 解決 問題の 事象 解決策 解決
事象の背後にある原因が違うと、解決策は 変わる 解決策B 解決原因B 原因A 原因C 解決策C 解決策A 問題の 事象
事象例：画像が重い  計測してみたら、画像が重いと出た  ベストプラクティス： 画像を軽量化しなさい→速くならない  過去の事例  Windowsのサーバを使っており、NTFSでフォーマットされたディスクパーティ ションを80%以上使っ...
大量の画像やらCSSやらJavaScriptを 配信すると…
Webの配信システムは複雑系 34 可用性 ユーザや顧客は、自社サイト に到達できるのか? ユーザや顧客は自社サイト に登録やログインできるのか ? 自社サイトに、主要マーケッ トの地域から到達できるのか ? 表示速度 ユーザや顧客は、自社サイ...
Chromeの開発者ツールではダメなの?
カバー率（経路）の問題
カバー率（時間）の問題
その速さ どこまで、いつまで保証できますか？
パフォーマンスの数値は一意に定まらない
平均の罠 1秒 2秒 3秒 4秒 5秒 6秒 7秒
ラプラスの魔 もしも、ある瞬間における全ての物質 の力学的状態と力を知ることができ、 かつ、もしも、それらのデータを解析で きるだけの能力の知性が存在するとす れば、この知性にとっては、不確実な ことは何もなくなり、その目には未来も （過去同様...
真の値には、 確率的に近づいていくしかない
病気の治療は、診察が大事 品質は、計測と分析が大事
治療＝改善作業
エンジニアは「医師」であるべき
データに基づく分析をしましょう!
レスポンシブデザイン前提の WordPressの高速化 Weakest linkを考える
表示速度改善手法 ベストプラクティス系  「Webの表示速度を高速化する10の手法」 部分最適化系  ハードディスクをSSDにしよう！  JavaScriptを高速化しよう！  「非同期処理」  PHP高速化  MySQL高速化...
Weakest Linkという考え  “A chain is only as strong as its weakest link.”  Webサイト配信においては、ネットワークが一番「弱い」
「ムーアの法則」に従って拡大しているイン ターネット網 http://iopscience.iop.org/1367-2630/10/12/123027/fulltext/ AS(autonomous system)レベルでのノード数の増加
インターネット網は今後、 ますます混雑していく
携帯網は、時間単位での配信容量が 物理的に増やせない ― 観覧車と同じ London Eye ― 定員25人
1ページあたり200KBを超えたら、 LTEでは物理的に3秒以内の配信はできない
熊本市 ― スマートフォンサイト
ページ容量 … 162KB
ウォーターフォール図
Yahoo! Japan ― スマートフォンサイト
ページ容量 ― 434KB
ウォーターフォール図 接続エラーが発生すると、足を引っ張る
Spelldata ― スマートフォンサイト
ページ容量 ― 318KB
ウォーターフォール図
WordPress高速化比較検証
何もしていないWordPressサイトと 高速化されたWordPressサイトの比較 高速化したWordPress 素の状態のWordPress
高 速 化 さ れ た WordPressVanillaWordPress
WordPressのホストのみの配信データ
WordPressのPHP処理（HTML生成）のみの 比較
WordPressを高速化しても ネットワークは高速化できない
画像、CSS、JavaScriptなどの詰め込み過ぎ が、WordPressの高速化を殺す
高速化の考え方のパラダイムシフト  「どこまで高速化するか」から「どこまで遅延を許せるか」へ  3秒以内に配信し切るための容量制限  3G通信 … 100KB  LTE … 200KB  容量上の制限が、物理法則上定まっているため、携...
Third-partyコンテンツとの付き合い方  現在の遅延の主たる原因は、Third-partyコンテンツにある  Google Analytics  広告配信  効果測定  SNS  きちんと計測して、遅延が見られた場合には対処...
まとめ  表示速度は、今や、表示開始0.5秒、表示完了2秒が世界標準です。  表示速度の高速化は、お仕事ですから、きちんと保証できるように しましょう。  保証するためには、計測しないといけません。  きちんと改善するためにはデータに基...
Q&A
レスポンシブデザイン前提のWordPressの表示速度高速化の考え方
Próximos SlideShares
Carregando em…5
×
Internet
9.978 visualizações
17 de Set de 2016

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

スマートフォンが普及するに伴い、マルチデバイス対応のWebサイトが求められています。その要望に応えるために、レスポンシブデザインを前提にWordPressでサイト構築することが一般的になっています。しかし、デスクトップサイトで使用するファイルをそのままに利用するレスポンシブデザインでは、その容量の大きさが、携帯網を経由して配信する際に大きな遅延要因となります。
今回のセッションでは、高速化の重要性と、正しい計測や分析のやり方、民法改正に関係するWebサイトの品質にも言及しつつ、WordPressで高速化できる限界と注意点について解説しています。

no profile picture user

  • Entre para ver os comentários

Exibir mais

レスポンシブデザイン前提の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

×