Webパフォーマンスの振り返り 2022年 - Webパフォーマンスについて
揺らぐ通信インフラへの信頼 今年、最も衝撃的だったのは、相次ぐ通信インフラの障害だったのではないでしょうか？ 絶大なる信頼を寄せていた通信インフラが障害で接続障害に陥る、というのは、日本人としては驚きの事態でした。 私たちの心の中には、「品質の日本」という自負みたいなものがあります。 サイレント障害 ネットワーク上で発生する、エラーとして検知されない障害を「サイレント障害」と云います。 その多くは、自社のインフラだけを見ていて、その稼働状態だけでシステム稼働の正常・異常を判断することが原因です。 携帯網については、有線回線とは異なる複雑な仕組みと、電波を使っているという事もあって、サイレント障害の検出のソリューションは、End-to-Endの通信監視・計測による手法が以前より世界で普及していました。 それを販売していたのは、ドイツにあるSIGOSという会社です。 世界で一番はじめにWebパ
「推測するな、計測せよ」のWebパフォーマンスにおける真の意味 - Webパフォーマンスについて
ソフトウェア工学で著名なロバート・C・パイク氏のCプログラミングに関する覚書というものがあります。 ルール1: プログラムがどこで時間を消費することになるか知ることはできない。ボトルネックは驚くべき箇所で起こるものである。したがって、どこがボトルネックなのかをはっきりさせるまでは、推測を行ったり、スピードハックをしてはならない。 ルール2: 計測すべし。計測するまでは速度のための調整をしてはならない。コードの一部が残りを圧倒しないのであれば、なおさらである。 ルール3: 凝った(Fancy)アルゴリズムは nが小さいときには遅く、 nはしばしば小さい。凝ったアルゴリズムは大きな定数を持っている。nが頻繁に大きくなることがわかっていないなら、凝ってはいけない（nが大きくなるときでさえ、ルール2が最初に適用される）。 ルール4: 凝ったアルゴリズムはシンプルなそれよりバグを含みやすく、実装する
HTTP/2が速いという幻想 - Webパフォーマンスについて
難しい話じゃないです。 皆さん、ご自分でChrome Developer Toolで簡単に確認できますから、やってみて下さい。 このブログでも、過去に統計分析をした結果は掲載したんですが、「盲信」はそうそう簡単には消えないようでして… takehora.hatenadiary.jp takehora.hatenadiary.jp 以下の図は、Chrome 63.0.3239.108での結果です。 CDNにFastlyでもAWS CloudFrontでも、どのCDNを使って実験して頂いても結構です。 CDNを使わずに、Webサーバ単体でも結構です。 同様の結果になります。 どちらもHTTPS通信です。 どちらも同じオリジン、同じファイル構成です。 HTTP/1.1は、Keep-Alive設定が入っています。 HTTP/1.1での配信 … Load Event 70ms HTTP/2での配信
はてなブログを自分で出来る範疇で高速化してみる - Webパフォーマンスについて
はてなブログの高速化について、はてなスターを外すと速くなるとか、色々話題になっています。 ユーザが手を入れられる範囲でどこまで高速化できるか、いつも私がやっている統計的品質管理のアプローチで、計測・分析・改善してみました。 デスクトップサイト計測 まずは、現状把握、Synthetic Monitoringです。 Synthetic Monitoringとは、実験計画法のフィッシャー三原則に則った、対象ページに介在して計測する手法です。 一ユーザとして、こちら側から、一定間隔で、対象ページにアクセスをして、表示速度に関するデータを取得します。 計測対象サイト takehora.hatenadiary.jp トップに乗っていた記事は、5.3MBあって、かなり重いです。 グラフ関係の画像を多用しているからですね。 計測条件 日本の帯域保証型(100Mbps)光回線 … NTTとKDDI 計測ブラ
HTTP/1.1とHTTP/2を比較する ― 第二回 ロリポップさんの検証サイト編 - Webパフォーマンスについて
ロリポップさんで、HTTP/1.1とHTTP/2の比較サイトを立ち上げられていたので、計測して比較しました。 lolipop.jp 計測対象サイト http1-1-contents.com http2-contents.com 計測条件 日本の帯域保証型(100Mbps)光回線を使用 NTT KDDI 計測ブラウザ … Chrome53 計測頻度 … 15分に1回 計測期間 … 4月12日～5月9日の29日間 計測ツール … Catchpoint Catchpointを知らない方のために説明しますと、CatchpointはWebサイトのパフォーマンスを24時間365日定常監視・計測するためのサービスを提供している企業です。 Googleの品質保証担当Vice PresidentだったMedhi Daoudiが2010年に立ち上げた企業で、現在、Google、Microsoftなどのテクノロ
Webパフォーマンスについて
揺らぐ通信インフラへの信頼 今年、最も衝撃的だったのは、相次ぐ通信インフラの障害だったのではないでしょうか？ 絶大なる信頼を寄せていた通信インフラが障害で接続障害に陥る、というのは、日本人としては驚きの事態でした。 私たちの心の中には、「品質の日本」という自負みたいなものがあります。 サイレント障害 ネットワーク上で発生する、エラーとして検知されない障害を「サイレント障害」と云います。 その多くは、自社のインフラだけを見ていて、その稼働状態だけでシステム稼働の正常・異常を判断することが原因です。 携帯網については、有線回線とは異なる複雑な仕組みと、電波を使っているという事もあって、サイレント障害の検出のソリューションは、End-to-Endの通信監視・計測による手法が以前より世界で普及していました。 それを販売していたのは、ドイツにあるSIGOSという会社です。 世界で一番はじめにWebパ
静的Webページパフォーマンス比較: AWS S3 vs Apache vs nginx Part1 - Webパフォーマンスについて
1秒を切るために 自社サイト(http://spelldata.co.jp)は、AWSのS3上に展開しています。 この自社サイトの計測値を見ていて、1秒を切れない計測点が現れているのが気になりました。 とあるお客様のサイトの高速化を行って、nginx+Wordpressで1秒を切るまでチューニングをしました。 それと比較して、静的なHTMLしか置いていないS3で1秒を切れない事があるのはどうかなと考えました。 この際、Apacheとnginxのサーバも立ち上げて、速度比較をしてみようと思い立ちました。 実験計画 比較対象 自社サイトコンテンツのトップページを計測して比較します。 この手の比較をする際に、負荷を徐々にかけて性能の変化を比較される事が多いのです。素の状態(負荷がかかっていない状態)で、どれだけの性能差があるのかを見るのは、基本性能を知るために欠かせないステップです。ですので、今
「超チューニング祭 ～ニコニコを超快適にしてみた～ in ニコニコ超会議３」の問題点 - Webパフォーマンスについて
来る2014年4月26日(土)・27日(日)に、「ニコニコ超会議3」が開催され、その中で「超チューニング祭 ～ニコニコを超快適にしてみた～」が開催されるそうです。 これは、現行のスマートフォンサイトのTopページのソースファイルを競技者がチューニングして、速度やデザイン・UIの改善をして、速度と使い勝手を競うのだそうです。 「これは面白そうだ! 会場は家から近いし!」と思って参加するつもりでいましたが、事前調査で計測してみた結果、フロントエンドのチューニングでは速くならないことがわかったので、その内容について説明します。 (主催者の方にも、フロントエンドのチューニングでは速くならないという情報は伝えてあります。) まずは、計測データ まずは実際のトップページ(http://sp.nicovideo.jp)の計測データを見てみましょう。 計測は、NTT DoCoMoとSoftBankの3G回
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
