Jonathan Cutrell「Obama陣営のエンジニア／デザイナーチームの一人に一問一答した」
Nettuts+ 2012.11.26のブログエントリ
Chatting with Obama For America’s Director of Frontend Development: Daniel Ryan | Nettuts+
- 2012年大統領選挙のObama陣営のネット戦略を担うエンジニア・デザイナーチームの中人へチャットでインタビュー
- 使ったツールから、教訓とか色々書いてる
- jekyll,cssプリプロセッサ、github、高速化ツール、ec2,s3,rails,django,magengo
- モバイルはトラフィック多い（全体の1/4）けど献金はほぼゼロ、とか
- 前回(2008年)の選挙のときは肝心なときにシステム障害を起こした件
- それを踏まえて今回はどうやったか
- Romney陣営は敵陣営の失敗から学ばなかった（肝心なときに同じ障害を味わった）
知らなかったこととか書いてて勉強になった
以下斜め読んだ内容
- Q：デザイン・開発チームにとって、大統領選期間の最大のチャレンジ
- A：
- たくさんのプロジェクトが毎日同時に動いてること
- いろんな要件がチームにどんどん飛び込んできた
- 資金集めだったり、支持者集めだったり、投票所への有権者の誘導だったり
- デザインは、支持者の意見、陣営のポリシー、法律等々を見て調整
- 数日、数時間で新規プロジェクトがスタートしてる
- Q：A/Bテスト、データドリブンな意思決定。どう使ったのか
- A：
- Obamaチームはデータドリブンとよく言われてるが、誇張されてる
- データドリブンなアプローチもあれば、そうでないもの色々組み合わせてやってた
- a/bテストツール：optimizely
- 毎日テストを走らせ、週次レポートでは、毎回ベストプラクティス、（PDCAの）Actionも載せてた
- 例えば献金での実績：前回比で125万ドル増加を達成
- Q：スタックの構成
- A：
- Q：使ったオープンソースのツール。プロダクション環境、デプロイ時のプラン
- A：
- jsのメインライブラリ：jquery、modernizr
- jqueryプラグイン：Fitvids.jsをよく使ってた
- テンプレートエンジン：mustache
- レスポンシブデザイン：やってみた。選挙陣営のサイト初じゃないか？
- cssプリプロセッサ
- less
- ツールはcodekit
- lessはチームのエンジニアに教えてもらったその日のうちに、less導入を完了させた
- 2011年10月のサイトテコ入れやってる時
- less導入のスピードの速さ
- 何かいい方法があればすぐ変えるような体制でやってたから
- git使った。ソースはgithubにホスト
- githubの中の人が書いてるgithub活用法をわりと忠実に守ってやってた
- How GitHub Uses GitHub to Build GitHub
- ローカルでブランチを切る
- レビューとテストできる段階になったらレポジトリに
- gitタグつける。レビュー、テスト、ステージング
- コードレビュー、QAやる
- masterブランチへプルリクエスト
- プルリクエストのレビュー。リードエンジニアとシニアエンジニアがやる
- 静的ファイル；S3にホスト
- サーバーサイドのコード；一旦DevOpsチームにデプロイリクエスト出す
- devopsチーム；puppetとgippetto使ってapk作ってた
- 小規模なコード変更：オンザフライでデプロイ
- 大規模なコード変更；新サーバクラスタにまずはデプロイ。内部テストしてから、古いクラスタと置き換え
- いつもこのフローでやってたわけではない
- 2011年8月にチームに参加したとき、dev環境、ステージング環境とかもなかった
- ステージング環境の導入はすぐに終わった
- cmsだけはローカル環境の構築とメンテがずっと大変なまま終わりを迎えた
- Q：サイトデザインの作り方
- A：
- デザインチームからたたき台
- エンジニアチーム、デザインチームそれぞれがアイディアを出してた
- データをもとに絞り込んでた
- クールなアイディアよりも結果出せるかどうか
- すぐれたデジタルエージェンシーの体制に近い
- PM、リーダー級メンバーが集まってキックオフ
- 方向性を決めててく、キックオフのメンバー間でフィードバック出し合ってまとめてく
- プロジェクトの中身がまとまったら、プロジェクトの中身を細かくしてく
- デザインはカンプ作ったり、エンジニアはプロトタイプ作り。これを繰り返す
- テストに回す
- 2012年夏ごろは１０以上のプロジェクトが同時に進んでた
- Q：ロムニー陣営は技術的問題を色々抱えてた。サーバー落ちたり。ハードウェア故障とか。Obama陣営はこの手の問題を回避に成功したきっかけ
- A：
- 自分（＝Daniel Ryan）は今回の選挙がはじめて。前回は中の人じゃなかった
- 前回の経験者がたくさんいた
- 2008年選挙のときにObama陣営のシステムで一度失敗を経験してる
- 投票者の動向をリアルタイムモニタリングシステムでHoudiniと呼ばれたやつ
- Romney陣営は今回の選挙では前回Obama陣営が失敗したシステムとよく似たシステム（Orcaと呼ばれた）を使ってた
- Orca Failed; but So Did Obama's 2008 Version of the Same - Ben Jacobs - The Atlantic
- 失敗をふまえ単一障害点をもつシステムを選ばなかった
- 冗長な構成にした
- 例えば支払いシステム
- Q：レスポンシブデザインは役に立った？モバイルファーストでデザインした？
- A：
- jquery mobileベースで最初開発。テンプレートは２つだけ
- テンプレート２つだけで回してるとスケールアウトできなかった
- トラフィックの1/4はモバイル経由
- モバイル経由の献金はほぼゼロ
- 2011年秋に大規模なテコ入れ
- モバイルファースト、レスポンシブで行くのが当然という感覚だった
- みんなゼロから勉強した
- モバイルファーストでは、横幅(width）でなく、低帯域にフォーカスするべき
- 320px幅のデザインから始めるのがモバイルファーストじゃない
- 低帯域環境でのエクスペリエンスから取り組むのがモバイルファースト
- モバイルファーストは包括的なもの
- コンテンツ作成では、ユーザフレンドリーにすること
- デザインは柔軟にしていくこと
- コードは量を切り詰めること
- Q：大規模なデプロイから一番学んだこと
- A：
- 有能なエンジニアの獲得が超大事
- 効率性の追求をできるエンジニアが構成するスタックの全てのレイヤーで必要
- スケールアウトが必要なときにその時点のチームでは力不足だった
- 有能な人が必要なことにすぐ気づいて雇うことができた
- Q：オバマチームのマネージメントの仕組み
- A：
- プロジェクトごとに変わる
- 献金、支持者集め、投票所への誘導。これが３大ミッション
- オンライン関連だと、デジタル部門、テック部門に別れるが、相互連携はかなり多く、自分（＝Daniel）は調整役として主にやってた
- obama陣営の中で、オンライン系チームは分離された形で機能してたが、陣営のオフライン／オンラインのおぼあらゆる局面に関係してた
- 次回（2016年大統領選挙）では、陣営の体制は今回までのヒエラルキーのある構造から、マトリックス構造に変わっていく、と予想してる
終わりに
- Danielのtwitter/blogで追加情報ある、かも
コメント欄
Strangeloop「wine.comにsite optimizerを導入してもらった件」
strangeloopnetworks.comで恐らく2012.4.13頃に公開された記事
Case study: Wine.com - Strangeloop
- 2012.4.13の公式アカウントでのtweetから公開日を推定
- ie6-7しか使えない環境から大量の注文が届き、ie6-7で注文出してくるお客はサイトの遅さにシビアで、商材への法規制が複雑かつ改正が頻発し、ページ表記を超柔軟に変えないといけない
- そんな商材（ワイン）のECサイト、7年目突入のwine.comにサイト高速化ツールSite Optimizerを導入してもらうまでの道のりを色々データ出して説明する、という主旨のエントリ
- wine.comのエンジニア達がコンバージョン上げるために、ABテスト、リソースの軽量化、色々最適化を続けた。けど「リソース足りない」のでツール探したのがきっかけ
- ctoのインタビューからとったコメントをもとに再構成。クライアントからのリップサービスも多い
- pdf版もあり
以下斜め読んだ内容
- はじめにwine.comのCTOのお言葉
- フロントエンド最適化ベンダーを調査してみて出した結論
- ベンダーの中でstrangeloopは突出してる
- グローバル展開してるサイトを高速化させた実績のあるのはstrangeloopだけ
- site optimizerはエンタープライズ規模でも対応できる唯一のプロダクト
- クライアントのサイトがクラウド使ってるとかそうでないとかも関係なく対応してる
- wine.com？
- ワイン専門のecサイトでは過去7年no.1。「internet retailer magazine」調べ
- 登録ユーザは100万以上
- ワインの種類は、1万3000種以上
- 2011年のデータだと、200万ボトル以上を出荷、昨対比35%増
- ギフトやアクセサリなどワイン関連の商材もある
- サイトではレビュー投稿、レーティング、リスト作成ができる
- 約4万人くらいのコミュニティができてる
- レビューやワインリストなどがシェアされてる
- Geoffrey Smalling（=wine.com cto）曰く
- パフォーマンスはローンチ直後から最重要課題
- 購入直後にお客からフィードバックをもらうようにしてる
- ceoはこのフィードバックの全てに目を通してる
- フィードバックのうち「サイトが遅い」系は全部cto宛に転送。結構な数が来る
- パフォーマンスがネックになってるのはモダンなECサイト共通の悩み
- お客はインタラクティブなエクスペリエンスを求める
- ニーズに応えるため、ECサイトはリッチなコンテンツをページに詰め込まないといけない
- コンテンツの詰め込みは代償がつきもの
- cto曰く
- リッチな機能と画像のデータ転送とレンダリングには所要時間が発生
- cto曰く
- wine.comの高速化へのもう１つの壁はIE6-7対策が必須なこと
- cto曰く
- 調査してわかったこと
- 購入金額の高いお客の中で金融系の会社の人がかなりいる
- 金融系のお客は職場から注文してる
- 金融系のお客の職場で使えるブラウザはIE6-7だけ
- ie6-7向けにはwine.comはまるで最適化されてなかった
- 金融系のお客はクソ重いページから注文を出す羽目になってた
- cto曰く
- データセンターのリージョンもまずかった
- データセンターは西海岸にあった
- 金融街のお客はたいてい東海岸にいた
- 地理的に離れてるので、ページ読み込み時間が更に遅れる要因となった
- ベストタイムで４秒という状態だった
- ページ読み込み時間が４秒かかること
- これで満足するECサイトも中にはある
- wine.comにとっては満足できる状態じゃない
- 「３秒以下」がwine.comの目標だった
- cto曰く
- 「読み込みに4秒」でよしとできた時は過去の話
- テクノロジーは進歩し、お客の期待は大きくなった
- 4秒じゃ遅い
- 「読み込みに２秒」はデカい目標だったのは昔のことで、今は達成しないといけない
- 達成できなければ、潜在顧客を失う。特に初回訪問者を失う
- 2009年からwine.comのパフォーマンス最適化はスタートしてる
- wine.comのデザインをリニューアルしたタイミングから
- cto曰く
- 当時リニューアルにはとても中の人たちはワクワクしてた
- 訪問者へ提供する情報をより豊かに
- ナビゲーションを合理的に
- 見栄えもよくなった
- お客により豊かなエクスペリエンスを提供できるという自負があった
- しかし待っていたのは、コンバージョンの大幅下落
- デザインリニューアル後のコンバージョン大幅下落の原因を中の人たちは探った
- 今回の新デザイン版と、簡易版でA/Bテストしてみた
- 簡易版はボタン３つ、２−３個の画像、コピー少々だけの構成
- テスト結果は簡易版の圧勝。コンバージョンも相当上昇してた
- cto曰く
- 当時中の人たちが痛感させられた事実
- お客は、素敵なデザインではなくサイトの速度を気にしてる、と
- 「速度大事」と気づいてからサイトのソースに手を入れた
- 簡易版の速度に近づけるように新デザイン版のソースに手をいれた
- テコ入れしていくと新デザイン版のコンバージョンは回復してきた
- 速度改善をサイト全体レベルで実施できるようにリソースを割くべき
- と、気付いたきっかけになった
- 2009年以降のwine.comのエンジニアチームが実行したこと
- サイトのソースに手を入れてパフォーマンス・チューニングを続けた
- 「サイト全ページで３秒以下に」の実現にはリソースが足りないと気付いた
- cto曰く
- wine.comでは1.3万以上の商品ページがある
- 各商品ページに対して、別バージョンが７つある
- 8バージョン必要なのは、ワイン出荷に対する法規制が州によってバラバラでお届け先次第で表記を変えるため
- お客がwine.comを訪問してリンクをクリックしたとき
- お客の居住州を突き止め、該当州への出荷にたいする法的制限の有無をチェックしたあとで、お客に合わせたページを表示させる
- これを３秒以下でやらないとダメ
- wine.comの高速化の課題おさらい
- ページはリッチコンテンツ
- ページは法規制にあわせて８バージョン用意
- ページはie6-7で閲覧される
- 洗い出した課題を解決するものをみつけるべくwine.comチームはリサーチを開始
- cto曰く
- 高速化のためのツール、サービスを探してみた
- strangeloopは抜きん出てた
- site optimizerは全てのブラウザ／OSに対応するツール
- セキュリティも万全だった
- site optimizerはかなり有望にみえた
- １つのツールを手軽なコストで導入するだけで、抱えてる課題全てが解決できるなら、相当すごいこと
- wine.comでのsite optimizer導入はあっという間に終わった
- 2010年のホリデー商戦に間に合った
- wine.comが重視する指標全てで劇的な改善を達成できた
ブラウザ別でみると最大で45%導入後高速化した
- cto曰く
- site optimizerは名前通りのことをしてくれる
- 全てのブラウザ／OS別の最適化をやってくれる
- 期待を裏切らないソリューションを使うのはとても気分がいい
- ブラウザ別平均ページ読み込み時間(2012.2時点)
- ビジネスにあわせてパフォーマンス最適化をさらにカスタマイズ
- サイト規模の恒常的増加が生み出す影響を減らす
- cto曰く
- 「読み込みを２秒以内に」はまだ達成できてないががんばってる
- wire.comのマーケティングの人はどんどん効果的ツール、コンテンツ、etc.をどんどん新たに編み出して導入しようとする
- この手の新規コンテンツ、ツールの導入は、パフォーマンス担当の人からすれば「負担が増えた」と映るの通常
- site optimizerは次々登場する負担を軽減するように働いてくれてる
- （補足）含意不明。どう軽減してくれるのかの説明が脱落してる
- 他のパフォーマンス系のツールと併用できる
- cto曰く
- 「これだけでOK」と言えるような、ページ高速化の万能薬はない
- パフォーマンスに意見のある人でもパフォーマンスに影響をおよぼす複雑な要因の絡まり合いを深く理解しているわけじゃない
- パフォーマンス改善は多方面からのアプローチが必須
- site optimizerはwine.comが導入してるサイト高速化のあくまで１つの（重要な）パーツ
- 高速化のために他にも手を打ってる。AakamaiのDynamic Site Acceleratorも使ってる
- パフォーマンス専門のエンジニアも招聘してる
- cto曰く
Guy Podjarny「Responsive Web Designなサイトは遅い、と言っておこう」
- Guy's Pod 2012.10.9のブログエントリ
- 追記
- 元エントリが更新されてたので、修正
- Guyのプレゼン動画聞き齧った内容も少し反映
Guy's Pod » Blog Archive » Responsive Web Design is bad for performance. There, I said it.
- 世界のトラフィックの数割を捌くAkamaiの中の人によるResponsive Web Designネタ
- Guyはモバイル向け速度計測ツール作ってたblaze.ioのCTOだった人
- blaze.io自体は2月にakamaiに買収された
- RWDに期待してる、人にも勧めてる
- けど認めるべき事実としてRWDは遅い、最適化してもどうにもならない部分残る
- その上でRWDでいくのに必要なこと、考えるべきこと、etc.を綴ったエントリ
- RWDが引き起こす速度低下は軽減できるがゼロにはならないでしょ、という立場から書かれてる
- 「RWDを頑張って高速化させる」系TIPSはあまり載ってない
- tips系は、エントリ途中でリンクしてる、スライドに詳しく載ってる
- Performance Implications of Mobile Design (Perf Audience Edition)
- 2012.4.16-18にOrlandで開催されたBDConfでGuyがプレゼンした時のスライド。プレゼン動画もvimeoにアップされてる
- Guy Podjarny - Performance Implications of Mobile Design - BDConf, April 2012 on Vimeo
- 数値、データ豊富でinformativeだが、リソース集としても有益
- rwdのパフォーマンスという（RWDシンパからはまず出てこない）切り口
- モバイル環境でのボトルネックについて事例つきで書いてる60枚くらいのスライド
以下斜め読んだ内容
- responsive web design
- 好きなアプローチだし筋はいいと思う
- けどRWDはとりあえず遅い
- RWDが遅くさせたwebを速くさせるのは結構難しい
- ハイパフォーマンスresoponsive web siteは不可能？
- そうは言ってない
- RWDダメ絶対？
- それも自分は言う気がない
- RWDは大抵の場合オススメできる
- RWDはページを込み入ったものにさせる
- そういう宿命
- 概して、モバイルで遅くなるよね
- RWDネタで書こうと思ったきっかけはTim Kadlecの良エントリ
- Blame the implementation, not the technique - TimKadlec.com
- Tim曰く、実装が良ければたいていの問題は解決できる
- Tim曰く、例えばRWDだって、正確無比に実装すれば高速化できるよ
- Timには一般的は同意できる
- 自分はRWDのパフォーマンスの悪さについて最近プレゼンしたことがある
- Performance Implications of Mobile Design (Perf Audience Edition)
- （補足）
- モバイル専用サイト、RWDなサイトのそれぞれのボトルネック、対策を解説してる
- モバイル専用サイトのボトルネック
- モバイルサイト本体には問題無し。軽量・高速
- PC版からのリダイレクトがボトルネック
- よくあるwww.hoge〜からm.hoge〜へのリダイレクトとか
- ESPNだと1.3秒のロス、ディスニー系サイトで2秒くらい
- httpのリダイレクト、js使ったリダイレクト、それぞれのコスト
- リダイレクトの最小化が、モバイル専用サイトの高速化のポイント
- RWDサイトのモバイルWebでのパフォーマンスの実情
- まずはmediaqueri.es
- Media Queries
- RWDなサイトのショーケース・お手本リスト
- スライド作成時点で掲載されてた347サイト。全部調べた
- webpagetest、解像度は４パターン、iphone/ipadは実機で
- PC版とほぼ同じリソース（html/css/js/img/json/etc..）をモバイルでもDLさせてる、とか
- 掲載サイトの5割〜９割は、ノーガード
- 86％のサイトで、DL量がPC/モバイルでほぼ同じ
- 11%のサイトで、DL量が減っても10%〜50%減の範囲
- 3%のサイトでだけ、DL量が50%以下に減らす努力やってる
- スマホで表示されてないコンテンツもPC版同様にDLされてます
- メディアクエリがPC向けcssロード自体はストップしてくれない、とか
- 「display:none」したってDLは止まらない
-
- 似た話として、css media queryやmedia typeも、DLの振り分けとかやってくれない
- smashing magzineは何か勘違いしてないか？
-
- PC版と同じ画像をDLさせてリサイズさせてるだけ。横行してる
- どうしてPC版並の巨大なDOMツリーがモバイル版でも構築してるんだ？
- RWDの成功例「Boston Gloveサイト」
- 表示はディスプレイサイズに合わせて可変。モバイルではシンプルに
- しかし、1400要素、4000ノードという巨大なDOMツリーが構築されてます
- 不要なリソースDL、過剰なDOMツリー
- これがRWDがモバイルWebを遅くさせる元凶
- RWD高速化TIPS
- 画像をなんとかできると一番大きい
- モバイルのトラフィック上位数千サイトでデータ取った
- リソースDLの67%は画像
- responsiveな画像DL
- サーバーサイド、クライアントサイド
- w3cで標準化が期待されてる部分
- Picture Element Proposal - Responsive Images Community Group
- 標準化されればimg要素を拡張しマークアップレベルで解決
- いわゆるmobile firstを読み替えて高速なモバイルwebへ近づく
- domツリーのサイズをモバイルに最適化。デザインにフォーカスするのではなく
- ミニマムなDOMツリーから、リッチな環境に合わせてDOMツリーをjsでエンハンスしていくアプローチ
- ミニマムDOMツリーからjsでエンハンスしていくアプローチ
- PC版でjsオフにしている人を無視してる
- jsオフにしてるPC環境は1%。彼らへの配慮と、モバイルでのパフォーマンスは両立しない
- どっち？と言われれば、モバイルのパフォーマンスを取る
- 解像度やレイアウト別にDLされるファイルを分けれるようにする
- レイアウトをコントロールするjsはインラインで書く
- 解像度に合わせてjs/cssダウンロードに使うscript/link要素のappendはdocument.write使う
- httpリクエストを減らす工夫。ファイル結合、htmlに直書き
- DLサイズ減らす工夫。minify。画像のフォーマット最適化
- 表示に必要なコンテンツを最初にDL。他は後回しにするDLの仕組み。オンデマンドなDLとかも
- 「@import」使わない
- m.hoge.comのようなモバイル専用サイトを比較対象に。DLされるリソースサイズの最適化を図る
- 計測ツール色々。計測しないと無意味
- mobitest,pcapperf(by google),icy(by stoyan stefanov),iwebinspector,webpagetest
- （補足）
- たいていのRWDなサイトがクソ重い原因は単に実装がクズ過ぎるせい、ということを言ってきた
- Performance Implications of Mobile Design (Perf Audience Edition)
- 自分はakamaiでこの手の高速化を自動的にやってくれるツール開発に取り組んでもいる
- たいていのRWDなサイトはモバイル環境で４〜５倍くらいは高速化できる
- とはいえ「RWDはwebを遅くする」という事実は揺らがない。今後も同じ
- RWDの問題は複雑さに起因する
- よくある「m.」なモバイルサイト（m.hoge.com、m.foo.com）
- シンプル
- htmlだけとかから作り始めれる
- 送受信されるパケットも軽量
- css,js,画像も少量で、それぞれが軽量（なことが多い）
- 他方RWDなサイト
- 複雑
- スマホでアクセスするとRWDなページはブラウザに巨大なhtmlをDLさせる
- やっとhtmlロード終わっても、js,css,画像の読み込みが更に始まる
- 可能な限りリソースの読み込みを回避する
- 可能だし、やるべき
- だが結構難しい
- 実装に問題のないRWDなサイトを作れた場合
- リソースの読み込みを避けて、コードが複雑化するのを避けることのできたサイト
- そのレベルに到達してもパフォーマンスは犠牲になる
- RWDなサイトをチューニングしまくっても、シンプル軽量なモバイル版（m.hoge..なサイト）の速度には追いつけない
- 同様なチューニングはモバイル版にも出来るから追いつけない
- 現状を見れば、RWDなサイトはモバイル版サイトよりも常に遅い
- ここまで言っておいてなんだが自分はRWDを支持してる
- 他人にもRWDをすすめる
- まあ速度は唯一重要なことじゃないから
- サイトの最適化をするというなら、最適化のリストに「高速化」が入ってないはナンセンス
- だが速度は唯一考慮すべき項目、という信条を持てるほど自分はナイーブじゃない
- 速度第一にしたら？と他人にも勧めることはない
じゃあどうすればいいのか？
- 今やってることをそのまま続ける
- RWDやってるならそれをプッシュする
- と同時にパフォーマンスのことを意識する
- エンジニア、デザイナーへ啓蒙する
- 彼らが「速度」のことを念頭に置くようにしてく
- 今日から今できる最善の手を打つ
- ブラウザベンダーに働きかける
- 高速なresponsiveなサイトをより容易に構築できるように
- responsiveな画像表示のために標準化プロセスへ持っていったような努力をしていく
- ビジネスの中に「速度」を組み込んでいく
- サイトが遅いことを要注意認定のバグなんだと考える風土を作ってく
- 実装する側にとって取っ掛かりになるよいリソースがある
- 事実を受け入れる
- RWDで作ることとは遅いサイトを作る事に他ならないこと
- RWDには代償がある
- retina対応の画像がよりリッチなコンテンツを可能すると同時に速度低下をもたらした。これと同じ話がRWDにも言える
- 事実を受け入れ、代償を減らすためにできることを積み重ねていく
- コメント欄
- Guyが丁寧にリプライしてるがinfomartiveだと感じる部分ゼロ
Tobie Langel「ios向け旧facebookアプリが遅かった件」
2012.9.15 public-coremob@w3.orgへのポスト
Perf Feedback - What's slowing down Mobile Facebook from Tobie Langel on 2012-09-15 (public-coremob@w3.org from September 2012)
- facebookがiosアプリをネイティブで作りなおした件について
- facebook.comにもポストした内容から、さらにパフォーマンスに話を絞って掘り下げた内容書いてて面白い
- この投稿自体にはレスが付いてないがinfoQがこのポストをネタに記事書いてて勉強になった
以下斜め読んだ内容
- ネイティブのiosアプリのリリース。なんで出したのか記事だした
- Under the hood: Rebuilding Facebook for iOS
- facebookが直面したパフォーマンス上の問題
- 詳しい説明が欲しいというリクエストが多い
- ということでポストした
開発ツール、開発用API
- ツールが無さすぎで、問題の切り分け大変すぎ
- facebookが直面してる問題はメモリに関係してるとみていた
- コンテンツのサイズがある大きさにになる
- アプリがデバイスのハードウェアのリソースを使い尽くしてクラッシュする
- こんなことがよく起こっていた
- 何が原因でクラッシュが起こってるのか突き止めるのがとても難しい状況だった
- GPUバッファを使い尽くしたからなのか
- リソース制限に到達したからなのか
- 他に原因があるのか
- 見極めるのが難しい
- デバイスに開発ツールが付属してない
- リモートでアクセスできるツールがない
- html5ベースのアプリ開発してるときに知りたかった（が手の届かなかった情報
- ヒープサイズ
- オブジェクトの数
- GCのサイクル
- GPUバッファのサイズ
- リソースの制限
- こういう情報は開発を終えた後でも有益な情報なはず
- 例えば。linkedin
- リソース制限（＝メモリに載せれる画像の量）をチェックするために、ハックしてしのいでる
- LinkedIn for iPad: 5 techniques for smooth infinite scrolling in HTML5 | LinkedIn Engineering
- (補足）
- ネイティブのAPI（ UITableViewController、 UITableView、 UITableViewCells）で享受できる高いパフォーマンスやメモリ効率の良さ
- これをhtml5ベースのipadアプリでどうやって手にするか
- linkedinのipadアプリの目玉UIのinfinity swipeの実装に施したハックの数々
- スクリーンの外にある要素に対して、スクリーンに近い順に、画像置換（src値のreplace）、隣のページへdisplay:none、さらに横のページにはページをremove
- 「display:none」とsrc置換の２つでクラッシュするケースの８割は解決できた
- 小技としてimgにwidth/height指定してauto-scale発動回避とか、css box-shadow禁止とか
- 没案として、UIWebVeiw複数使ったらダメだったとか
- linkedinはそうやってアプリのクラッシュを回避してると記してる
- (補足）
- デバイスのメモリリソース情報についてアクセスできるAPIがあった方がいい
- 認証必須だとしてもAPIがあった方がいい
- fps
- ハードウェレベルでのfpsが測定できない
- これはアプリのテストに致命的
- ACTION-27: Fluidity of motion and consistency of framerates from Robert Shilston on 2012-08-13 (public-coremob@w3.org from August 2012)
- 例えばUIデザインでinfinite scrollingにするかpagenationにするか決めたい時とか
- fingerprintingの点で注意すべきなのは承知してる
スクロールのパフォーマンス
- このパフォーマンス上の問題についてはw3cのworking groupで議論始めてる
- これも重要な問題の１つ
- タイムラインを流れるnewsfeedで問題になる
- inifinite scrollingを使ったUI
- ユーザのスクロールに合わせてコンテンツを先読みしてコンテンツを継ぎ足してる
- どんどん継ぎ足してると、コンテンツの総量がとても大きくなる（画像、テキスト）
- 現時点の実装ではjsでスクロールを実装してる
- 他の実装では速度でない
- 他の実装では色々問題がある
- 実装でぶつかってる問題を箇条書きで
- 必要なものを箇条書きで
- スクロールは高速かつ滑らか
- ユーザのengagementには必須
- ユーザが読み込み済みコンテンツの下端に近づくと、定義済のイベントを発行され、ンテンツが先読みされ、位置が算出され、継ぎ足される
- 滑らかなスクロールを殺すことなく、スクロール中も新規に読み込まれたコンテンツが継ぎ足される
- i/o処理や計算をバックグラウンドで実行できること
- 滑らかなスクロールを殺さないため
- たくさんコンテンツがあっても滑らかなスクロールを維持できること
- 画像が沢山あっても維持できること
- こんなAPIが欲しい
- 現状ブラックボックス状態で、わずかなハックが使えるだけ
- エンジニアはハックに頼ってハードウェアアクセラレーションを使ってる状況
- David Walsh考案
- Force Hardware Acceleration in WebKit with translate3d
- GPUバッファのサイズはデバイスを消費してるコンテンツサイズに相対的？
- だとすればの話だが
- GPUの管理がブラウザに委ねられた状態が相当な間理にかなった形で続くことになる
- とはいえGPUにアクセスできるAPIを提供する点についてはpro/con色々ある話
その他足りないもの箇条書きで
- タッチイベントのトラッキングの精度向上。特にandroidで
- よりスムーズなアニメーション。常に重要
- キャッシュ性能の向上
- app cacheは実用レベルにない。使わないことにした
- MoPad: appcache-london
- （補足）
-
- FT labがホストになって2012.8.14開催されたmeetupのログ
- FT、Economist、facebook、google、Lanyrdなどモバイル用html5アプリ経験のあるエンジニアが参加
- 事例紹介し、オフラインのストレージ機能のハマった点、ハック、どこに使ってるかとかと共有
- ノウハウ共有から進んで、app cacheが本来持つべき機能(jsからキャッシュの更新・削除できるapi用意するetc.)、ダメなとこ（master entriesは元凶だ、etc.）、詰め切れてないとこ（キャッシュの適切なサイズについて「これくらいだろ？」という感覚が共有できてないetc.)
- w3cに整理整頓されたver.あり
- Meeting notes 14 August 2012 - Fixing Application Cache Community Group
-
- （補足２）mountain viewでも同じ趣旨のmeetupが2012.9.24に。twitter,MSも参加
Adam Langley「CRIME attackの件」
ImperialViolet 2012.9.21のエントリ
ImperialViolet - CRIME
CRIME attackについて
- 現時点での対応
- fxと若干違う対応してる点
- 今後のchromeでの対応プラン
をchromeチームのエンジニアがざっくり書いてる
spdy/4で完全対応なんだろうが、それまでのプランの具体的なところを知れてよかった
以下斜め読んだ内容
- 前から気になってた問題
- chromeチームが今回作ったパッチの話
- その前にspdyがヘッダを圧縮する仕組みをおさらい
- zlibのやってることは一言でいうと
- このリテラルバイトを出力
- xバイトに戻ってこいつ（=xバイト）からyバイトを複製
- 圧縮の仕組みの参考になる図を用意した
- 下線ついた文字列＝コピーされるテキスト
- 濃い青の下線部分
- ダイアグラムの中にオリジナルが存在するテキスト
- 灰色線の先にオリジナルのテキストの場所が指示されてる
- 薄い青の下線部分
- 辞書に用意されてる文字列にオリジナルを持つテキスト
- spdyでは共有テキストが定義されてる
- 共有テキストにはヘッダにあると予想される文字列が入ってる
- この共有テキストをzlibが利用する
- 辞書が圧縮のときに有効利用されてる
- CRIMEが光を当てた問題
- zlib使って保護された情報を解読していく手法の詳細はDuongとRizzoのプレゼンが詳しい
- ネットワークトラフィックを監視でき、自在にhttpリクエストを出せる
- この条件をクリアすれば攻撃者はCRIME attackを実行できる
- jsをページに仕込むとかして、ターゲットのセッションを読んで、解読とかできる
- CRIME attackの話を聞いた時のchromeチームの状況
- spdy/4に搭載する圧縮の仕組みを設計してる真っ最中
- この新搭載の圧縮の仕組自体はCRIME attackを回避できる仕組みでもあった
- プロダクトに同梱済みのspdy/2やspdy/3については色々やり残しがある状態
- CRIME attackへの対応
- chrome22以降でspdyのヘッダ圧縮を復活させたい
- ヘッダ圧縮というspdyの機能は捨てがたい
- 転送データ削減につながるから
- spdy/4はまだリリースできる段階にないのでシンプルな解決はできない
- chrome22,23では複雑なやり方で解決させるつもり
以上はあくまでざっくりした説明
- ここで説明したことに対応するコード、脆弱性のないzlibストリームを生成するコード
- クリーンなパッチではない
- spdy/4が準備できたら捨てる代物
- だが、ヘッダ圧縮を復活させれるのはメリット
- 縮小してるがダイアグラムの別のサンプルを載せた
Drew Olanoff「Mark Zuckerberg曰く『html5に賭けるなんて大変な間違いをしてしまいました』」
- teccrunch 2012.9.11のエントリ
- San Franciscoで開催中のDisrupt 2012の一コマ
Mark Zuckerberg: Our Biggest Mistake Was Betting Too Much On HTML5 | TechCrunch
ios向けにネイティブアプリをリリースした件について率直に書いてる
日本語版techcrunchの翻訳対象外になってる
以下斜め読んだ内容
- Mark Zukerbergがfacebookのモバイル戦略について色々言ってる
- ネイティブアプリじゃなく、html5に乗りかかりすぎだった過去
- html5偏重はモバイル戦略で犯した大きなミス
- html5にフォーカスしたこと自体が間違いだった
- Markが公にhtml5偏重＝間違いだと認めたのは初
- facebookの状況はネイティブアプリリリース後好転
- ネイティブアプリ投下後の反応
- mark曰く、フィードを読んだりポストしたりする数が倍になった
- mark曰く
- プロダクト開発の速度が今年前半は遅かった
- 後半はどんどんとってもクールなもの出せると思ってる
- 「とってもクールなもの」？
- おそらく、マネタイズ絡み
- facebookにとってモバイルは広告収入への鍵、ということが見えつつある
- Zuckerberg Says “On Mobile We Are Going To Make A Lot More Money Than On Desktop” | TechCrunch
- 使ってるツールに一蓮托生な状態から一気に方針転換することはとっても大変
- 去年FB CTOと僕ら（＝techcrunch）でモバイルの未来のことで話をした
- CTOとの話をネタに記事も書いた
- Facebook CTO Bret Taylor On HTML5, Mobile As The Future, And Yes, FriendFeed | TechCrunch
- 当時のCTOはBret Taylor
- facebookは相当html5に入れ込んでたのがわかる
- 参考にhtml5ゲームについてfacebookと話をしてるくだりを抜粋で再掲
- flashを捨て進化していく
- 今fabookでリリースされてるhtml5ゲーム
- かつてはflashがその役割を担ってた部分
- bretにこのへん突っ込んで聞いたら無難な答えくれた
- bret曰く
- flashを捨て進化してくことは大変。今曲がり角の時期に来てる
- flash->html5への移行で色々ギャップ出てきてる。できる限りそれを潰していく
- bretは、未来の主戦場はモバイルと認識してる
- モバイル環境に乗り込んでいき、いろんな問題にぶつかってる
- bret曰く、モバイルのユーザ規模は今後は変わる
- 今支配的なデバイスが未来永劫支配的とは限らない
- bretは明言しないがそう考えてる
- 現在支配的な地位にあるデバイスが別のデバイスに取って代わる。これが実際に起きたとする
- facebookが大量のリソースを今一番使われてるデバイスに注ぐべきか
- むしろfacebookはhtml5にリソースを注ぐのが楽な道じゃないのか？
- html5というか、今後登場してくるたくさんのデバイスで良い感じに動いてくれるような何か
- （補足）
- モバイルデバイスの世界は変化が激しい
- Bretもそう感じてた
- ネイティブアプリを作ってデバイスの力をより搾り出せる
- アップルのような大企業はいつも力説してるところ
- 動画（３０分くらいある）
- あとでかく
Guy Podjarny「SPDYはみんな思ってるものと違う」
Guy's POD 2012.6.12のエントリ
Guy's Pod » Blog Archive » Not as SPDY as You Thought
- AkamaiでChief Product Architectという肩書きを持つエンジニアによるspdy検証エントリ
- コメント欄も盛り上がってる
- Steve SoudersやSPDYテストしてるgoogleの人（Matt Welsh）とか
- Guyがspdy rantじゃないことがよくわかる
- 「spdyいいよね」「高速化tipsの賞味期限」「spdyはここ変えたら凄くなる」等々議論してて楽しい
- Guyのポイントはまとめると
- spdyに手を出す前にサイト高速化のベストプラクティスを実践しろ
- お前らの糞重いサイトのボトルネックはhttpじゃない
- 広く使われてる高速化のテクニックの中にはSPDYの現在の仕様と相性悪いものがある
- spdyはリクエスト／レスポンスの多重化を「ホストを問わない」形に変えるともっと良くなる
以下斜め読んだ内容
- spdy良い技術
- httpの過去１０数年で初の実用レベルのアップデート
- spdyが取り組んでる問題
- モバイル環境での高いレイテンシ・低パフォーマンス
- webのセキュリティ
- spdyとhttpの違いは色々
- tcpコネクション1つ（もしくは少数のtcpコネクション）上でリクエスト／レスポンスの多重化の実現が大きい
- 巷にはspdyのベンチマークをみかける
- 曰く「ページ読込を倍速に」やら「モバイル環境でspdy/httpsがhttpよりも23%高速」とか
- Chromium Blog: A 2x Faster Web
- SPDY performance on mobile networks - Google Developers Blog
- 自分も実際のサイトで試した。でも宣伝されてる通りにならなかった
- 自分のテストが示す限りspdyは「httpsより僅かに速い」が「httpより遅い」
- 巷のベンチマークと自分のテスト結果が食い違う理由は簡単
- spdyはhttpより良い。これは本当
- たいていのウェブサイトにおいてhttpがボトルネックではない
長すぎて読みたくない人向けに。最初にまとめ
- alexaのデータで上位500サイトピックアップ
- 各サイトでページ読込時間をテスト
- 各サイトにhttps+spdy、httpsのみ、httpの３パターンをテスト
- spdy対応クライアントにchrome
- spdy対応サーバとしてContendoをchromeと各サイトの間に置いた
- 同じ条件で各サイトをテストするため
- Contendo側でhttp/http/https+spdyをスイッチ
- テスト結果
- 自分でテストする気になったきっかけ
- 出回ってるベンチマークが現実離れした環境でテストしてたから
- （補足）
- guyが説明のために使ってる言い回し
- 1stパーティコンテンツ、サードパーティコンテンツ
- サイト運営側がコントロールできるコンテンツなのか、どうか
- 別サーバー、別ドメインから読み込み、改変等できないコンテンツ、リソース
- ソーシャルプラグイン、とか
- サードバーティコンテンツの典型例
- 自分のテストは過去のテストと比べて条件がいくつか違う
- 1stパーティコンテンツにのみspdyを有効化
- 3rdパーティコンテンツはサイト運営者がspdy化／オフ、とかコントロールできないから
- 便宜的に1stパーティコンテンツが複数のドメイン／サブドメインに分散してるのを１ホストにまとめてる
- サードパーティコンテンツは除外
- 過去のベンチマークだとサードパーティコンテンツも静的なコピーを作って１ホストにリソースがまとまっているような状態でテストしてた
- こういうのは自分のテストではやってない
- これは実態と異なる人工的環境でのテスト
- spdyが実戦投入される環境からかけ離れてる
- リバースプロキシを使いクライアントサイドプロキシは使わない
- クライアントサイドプロキシを使うとダメな理由
- クライアント／プロキシ間に余分にリクエスト／レスポンス発生
- リクエスト／レスポンスを多重化できるspdyが活躍できる状況だがよくある状況でない
- 架空サイトじゃなく実運用されてるサイトをテスト
- パフォーマンスの最適化ができてる部分、全然な部分とか本当それぞれ
- そのままテスト
- ページ読込の最適化が全然であっても、そのままに
- バックエンドが不効率であっも、そのままに
- パフォーマンスの最適化ができてる部分、全然な部分とか本当それぞれ
- 巷でみかけるspdyベンチマークの対象サイトは２パターンに収まる
- google傘下のサイト
- 高速化のチューニングをきっちり
- 動的／静的なコンテンツが複合的に使われてるサイトを、完全静的に作り替えたバージョン
- 実運用されてるサイトの数々のボトルネックがテスト前から刈り取られてる
- google傘下のサイト
- 自分のテストの良し悪しを判断できないという形にはなってないと思う
- 巷でみかけるテスト結果と自分のテスト結果は結構違う
- でも、これだけ違う理由を十分に理解してもらえるはず
- 多くのウェブサイトにとってspdyが救世主にならない理由は色々
- 大きな理由は２つ
- 理由1。webページのリソースが複数ドメインに分散
- リクエストの多重化は「原則」ドメインごとにしかできない
- 「コネクション数激減」というspdyの最大の長所が削がれる
- 「ドメインごとに多重化」には例外あり
- SPDY and IP pooling
- （補足）
- 理由２。spdyでは解決できないwebページのボトルネックが複数ある
- spdyはhttpよりも良い技術。
- たいていの遅いページのボトルネックはhttpじゃない
テスト詳細
- spdy対応ブラウザ、spdy対応リバースプロキシが自分のテストには必要
- アメリカのトップ500サイトをAlexaから抽出
- トップ500にはアダルトサイトもあるが「これが現実の姿」ってことでこのままテスト
- Contendo CDNをリバースプロキシとして使った
- クライアント側のchromeはWebPagetest上で動かした
- WebPagetest - Website Performance and Optimization Test
- Patrick Meenanに助けてもらった
- WebPagetestを使うとchromeでのテストを自動化できる
- テスト時点ではchrome18
- 実はchromeは実行時間の5%はランダムにspdyを無効化してる
- WebPagetestはテスト結果から無効中のデータを自動的に除外してくれる
- WebPagetestではテストするネットワークの速度選べる
- Cable/DSL/遅いモバイル／速めのモバイルの４環境でそれぞれ５回テストした
- テストしたwebサイトの1stパーティのリソースが1ドメインだけにある場合と複数ドメインに分散する場合があった
- 別ドメインのリソースを同一ドメインにあるかのように配信できる機能がある。これを活用
- ネットワークの一時的な変化がテスト結果にバイアスを与える可能性を考慮
- テストを昼間２回、夜中1回の計３回実施
- 累計9万ページロードした
- http/https/http+spdyそれぞれ3万ページロード
- 統計的な正確さに必要な回数よりも多くテストした
テスト結果
- spdyはwebページを速くしてくれなかった
- テスト結果のデータは同じ結論を示した
- 数値は多少変わるかも。そこは重要じゃない
- 速い／遅いが数%レベルに留まってるのがポイント
| ネットワーク速度 | SPDY vs HTTPS | SPDY vs HTTP |
| Cable | SPDY 6.7% faster | SPDY 4.3% slower |
| DSL | SPDY 4.4% faster | SPDY 0.7% slower |
| モバイル（低レイテンシ） | SPDY 3% faster | SPDY 3.4% slower |
| モバイル（高レイテンシ） | SPDY 3.7% faster | SPDY 4.8% slower |
- Cable
- down5,000Kbps、up1,000Kbps, レイテンシ28ms
- DSL
- down1,500Kbps、up384Kbps, レイテンシ50ms
- モバイル（低レイテンシ）
- down780Kbps、up330Kbps, レイテンシ50ms
- モバイル（高レイテンシ）
- down780Kbps、up330Kbps, レイテンシ200ms
spdyは良い技術なのに、なんで速くならない？
- 一言で言えば、実際のボトルネックを解決しないから。
- 使ってるドメイン多過ぎ
- spdyによる高速化はドメイン単位に分割される
- 仮にページが読み込むリソースがそれぞれ別ドメインにあったら、spdy化は益無し
- ページのリソースが多くのドメインに分散してるwebサイトは最近増えた
- サードパーティドメインのリソースである場合が多い
- spdyが力を発揮できない
- ページが使ってるドメインの数
- 自分のテストしたデータだと、平均18ドメイン／page
- そのうち半分以上のリソースが、htmlファイルがあるドメインとは別のドメインにある
- 9ドメインで1度リクエスト出すだけのために専用のコネクション作ってる
- 4ドメインで2回リソースを転送するだけのために専用コネクション作ってる
- この13ドメインではspdy使うメリットが当然見えない
- 18ドメインでspdy有効化されても結果変わらなない
- spdyは接続ドメインの数を減らせない
- 平均コネクション数をページ単位で比較
- 各ドメイン単位でのコネクション平均を比較
- リソース読込のブロック頻発してる
- ページ読込時に起こること
- js/cssがロードされ処理されてる間は画像の読み込みはブロックされる
- ページ読込時に発生する処理のブロックはspdy化しても変わらない
- ページ読込時に起こること
自分がやったテストから活かせそうなこと
- webサイト運営者
- 「spdyの御利益」の理解を訂正すべき
- spdy化から得られるメリットをMaxにしたい？
- ならば、ページが読み込むリソース群が使ってるドメイン数を最小化しろ
- フロントエンド側でのボトルネックを潰しておく
- 実施して無駄になることはない
- ブラウザベンダー、spdyコミュニティの住人
- spdyは自分も注目してる技術だし、あるべき発展の途上にある技術
- spdy使うは時間の無駄といいたいわけじゃない
- spdyには改良の余地、高速化の余地がある
コメント欄
- Q：spdy+tlsのテストになってて、spdy単体のテストになってないのはダメでは？
- A：
- 実質的にはspdyにはhttpsが必要
- spdyはtlsの高速化に貢献するという見方が成り立つ
- spdyのプロトコル自体はsslを要求しない。これは正しい
- 現実の環境ではtls抜きだとspdyリクエストを通すゲートウェイもミドルウェアは１つもない
- テスト環境では、Cotendo(CDN）とウェブサイト間はhttp接続
- ウェブサイトへのアクセスにhttsは要求されてないから
- googleがspdyについて出してる数字を疑ってるわけじゃない
- 現実世界ではgoogleの出してる数字通りにいかないことをテストして示した
- サードパーティのリソース使うのを止めるのはspdyの有無に関係なく高速化にとって重要
- サイトが現状のネットワーク環境に最適化していくとは考えてない
- spdyやhttp2.0が実運用されてるウェブサイトに最適化していくと考えてる
- Q：by Steve Souders
- テスト結果について異論無し。指摘しておきたいこと数点
- トップ100のサイトはページ速度の最適化についても下位サイトよりも徹底してる
- 比較のためにHTTP Archiveを参照する
- 上位100サイトのPage Speedスコア平均は90ポイント
- これが上位1000サイトだと、83ポイントにダウン
- さらに上位20万サイトだと、74ポイントまでダウン
- 傾向として、高速化のための実装をあまりやってないサイトの方が、SPDYの恩恵を受けやすい
- 500以下のサイトで同じテストやった方がSPDYの効果は大きくなるはず
- Guyのテスト対象は上位500サイトだけだったから、テスト対象を色々変えてテストしたらより有意義な結果でるはず
- 複数のドメインにリソース分散してるサイトはSPDYと相性悪いのは確か
- domain shardingを使うことを高速化のためのtipsとしてここ3年間提唱してきた
- SPDYが使われてない環境ではdomain shardingは結構普及した。特に上位サイトでその傾向高い
- 上位５０位サイトのうち25サイトでdomain sharding使ってる
- domain shardingが登場する前からspdyがあれば、このテクニックは普及しなかったと思う
- ちなみに上位サイトピックアップには、HTTP Archive使ってる
- A：
- 上位サイトでもサイトが遅くなるような設計してる
- レンダリングなど他の処理をブロックするスクリプト読み込み
- 重くなるのが目に見えるjavascriptの書き方
- キャッシュを活用するとか考えてられない
- サイトが遅いことに何ら手を打ってないサイトにおいてhttpはボトルネックになってない
- domain shardingとSPDYの相性の悪さは解決可能
- 今のspdyのスペックではホスト別になってる
- リクエスト／レスポンスの多重化があくまでホスト別になってる。ここにテコ入れ
- １つのコネクションで複数ホストのリクエスト／レスポンスを捌けるようにする
- Q：by Matt Welsh @google
- モバイルネットワークの検証で実機使ってなくない？
- googleのモバイルウェブパフォーマンスチームがspdy化すると23%高速化できたと前にリポートした
- ここでは実機使ってテストしてる
- ただし、ページのリソースが複数ドメイン／ホストにまたがってるサイトはテストしてない
- 今後テストしたい
- プロキシーもforward proxyでテストした
- A：
- 実機使ってない、EC2上のデスクトップ版chromeでテスト
- 手軽にモバイル環境をエミューレートできると思ったから
- モバイル環境は高速化に関してデスクトップ環境とは異なる条件がたくさんある
- 実機使って同じテストを今後やりたい
- AkamaiファミリーのMobitestをパワーアップしたらできるかも
- forward proxy使った環境でspdyのテストをすること自体には価値がある
- プロトコルとしての評価には有益
- サードパーティーのドメインのリソースをページに使うこと自体はどんどん悪い方へ向かってる
- 現状をspdyやブラウザがどう振る舞って行くのかを注視したほうがいい
- 現時点の環境のもとでspdyを使うときのベストプラクティスを広めてく活動が必要
- Q：追試したいけどCotendo CDNは無料？
- A：Cotendoのサポートに連絡してくれ。
- Q：
- テストを実施したタイムゾーンは？
- Cotendo CDNサーバーから離れた場所との通信は試した？
- A：
- EC2サーバは東海岸のリージョン
- Cotendoの CDNサーバはNew York
- これ以外のパターンは試してない
- Q：Cotendo〜オリジナルサーバ間のレイテンシをどうやって割引いてベンチマーク結果だしてる？
- A ：
- http,https,spdyの３つとも全てのテストはCotendoを経由
- テスト結果に影響出てる
- 通常介在しないプロキシがある分、余分な通信時間発生してるという意味では
- ただし全てのテストで同じように影響出るので、比較には困らない
- Q：Cotendo〜オリジナルサーバ間
- この区間でどうやってspdy接続をエミュレートしてる？
- Cotendoサーバに全てキャッシュして、Cotendo〜オリジナルサーバ間の通信は省いたテストの方が正確では？
- A：
- クライアントからのspdyリクエストが出るとCotendo CDNはたくさんコネクションを開いてオリジナルサーバへリクエスト投げる
- 通常のhttp通信で発生するリクエストの処理待ちが出ないようにエミュレートしてる
- Cotendoのコネクションのやり方は、webの屋台骨で使われてるやり方と同じ。だからとても早い
- キャッシュするやり方は別の検証方法として面白いかも。ただ別のバイアスが生まれるかも
- （補足）
- リクエスト／レスポンスの多重化のエミュレートはわかったが、ヘッダ圧縮をどうエミュレートしてるのかわからん
- Q：
- テスト結果が遅いのは当たり前では
- cdnからウェブサイトへの接続がhttpになってたら意味ないんでは？
- cdn経由のレイテンシを差っ引いたとしても、多くのhttp接続を確立・破棄するコストがあるし
- A：
- ブラウザがhttp通信で困る部分は、CDNのhttp通信には当てはまらないことが多い
- CDNはブラウザよりも遥かに多くのコネクションを張れるし、貼りっ放しにもできる
- CDNはウェブサイトへのリクエストの多重化を多くのコネクションを確立することで実現してる
- CDNを経由することことに由来するレイテンシはもちろん発生する
- spdyはブラウザ〜サーバ間通信の「ゴール直前」部分（ブラウザとCDNの間）で起こる問題を解決するために設計されてる
- 多くのウェブサイトにおいて、spdyはそのウェブサイトが使ってるCDNで実装されるのが王道
- ここではCDNはウェブサイトのフロントエンドサーバだから
- 自分が行ったテスト（ブラウザ〜ウェブサイトの間にspdy対応したCDNを置いてテスト）は現実的な環境を想定してる
- ウェブサイトのオーナーが実際にspdyを導入するときに使うシナリオ（フロントエンドサーバでspdy実装）に忠実
- パフォーマンスのテストは難物
- spdyが実戦投入される一番リアルなシナリオにそったテストだと思う
- 一覧リアルなシナリオでのテストを今回実施して、分かったことをシェアしておこうと思った
- Q：by Catchpointの共同創業者
- あとでかく
- A：
- あとでかく
