みなさんは自社のWebサイトのHTTPプロトコルのバージョンをご存知でしょうか？
ほとんどのブラウザで「ページの情報を表示」を選択すると、HTMLページのヘッダ情報を見る事ができます。そうすると、下記のような情報をみることができます。
HTTP/1.1 200 OK
Date: Sat, 02 Oct 2010 13:12:41 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.2.6
これをみると、このページは
- HTTP プロトコルは 1.1 を採用
- WebサーバーのOS は CentOS を採用
- Webサーバーは Apache/2.2.3 を採用
- PHP 5.2.6 を採用
等といった情報が読み取ることが出来ます。
この、HTTPプロトコルのバージョンがページの表示速度に大きく影響します。
何が違うのか？
大きく2種類の違いを把握すると理解しやすいと思います。
1. 並行処理できる数が大きく違う
Webサーバーとの通信の回数が多いほど、その差は歴然です。以前に「Webサイト高速化技法（１）：物理的に近い場所にWebサーバーを置く」http://uehama.blogspot.com/2010/08/webweb.html という記事を書かせてもらってますが、その中で例えば HTML ファイル中に画像が50種類呼ばれているとすると、50個を同時にWebサーバーに取りに行く事はできずに、並行処理をしながら数回に分けて取りに行きます。その同時に出せるリクエストの数が HTTP/1.0 と HTTP/1.1 では違います。なので読み込むファイルの数が多ければ多い程、その差が大きく拡がっていくととになります。
2. 1回のリクエスト／レスポンスの中身が違う
あまり技術的にしたくないので詳細は割愛しますが、HTTP/1.1 ではファイル1個を取りに行く時のリクエストとレスポンスの作業の効率化が図られています。画像ファイル1個を受信しようとした時、複数個のボールをサーバーに投げて複数個に分けて返していたのを、1個のボールの受渡しにまとめた感じです。これも経路が効率化されますので、ページ表示速度が大きく変わります。読み込むファイルの数が多ければ多い程、その差が大きく拡がっていきます。
もうすでに HTTP/1.1 に移行が終了していると思ってましたが
もともと私は全ての企業が HTTP/1.1 に切り替わっていると思っていたので、このような記事を書こうとは思っていなかったのですが、念のため調べてみるとちょっと予想外の結果になったので紹介します。
私が毎週報告している Google Analytics の導入状況調査を利用して、上場企業3828社のプロトコルを調べてみました。すると
HTTP/1.0 の企業がまだ 60 社も残っていました。
明らかにページ表示速度は変わります。変更するのはすぐに出来ますし、予算もかかりませんのですぐにでも変更されるのをおすすめいたします。
みなさんの会社の Webサーバーは HTTP/1.1 になっていますか？
一度確認してみてください。
それでは。
2010年10月2日土曜日
2010年9月16日木曜日
Webサイト高速化技法（４）：難読化のメリット／デメリット
Webサイト高速化技法（４）：難読化のメリット／デメリット
「難読化」という技術、ご存知でしょうか？
元々はソースコードが読める HTML/JavaScript の世界での流用や悪用、著作権被害などを防ぐために記号化し読みづらくすること、というものでした。ですが、最近は難読化したものを読みやすくするもの等も出てきており、あまり流用防止の為に難読化するというものを見なくなり、著名なライブラリが著作権対策の為に施しているもの以外では使われなくなってきたように思います。
難読化には別の使い道が
この難読化ですが、実はパフォーマンスに結構影響します。
- サイズが小さくなることで読み込み速度があがる（数%）
- 変数名が小さくなるのでローディングが速くなる（数%～数10%）
- メモリ使用量が小さくなるのでキャッシュ回数が減り実質速くなる
などでトータル20～30%速くなることもあります。
- サイズが小さくなることで読み込み速度があがる（数%）
これは想像できますね。サイズが小さくなる事は画像なども同じで表示速度に大きく影響します。
- 変数名が小さくなるのでローディングが速くなる（数%～数10%）
これは分かりますでしょうか？実はこれが一番スピードに影響します。
「a」と「b」を比較するのと、
「abcdefghijklmnopqrstuvwxyz」と「abcdefghijklmnopqrstuvwxyz2」を
比較するのは人間の目でも明らかなように、PCでも速度は大きく違います。
これらは初期ローディング時に自動最適化を行い、2回目以降はキャッシュを利用することで速く実行する技術も採用されてますので、2回目以降はそんなに変わらなくなってますが、初回は大きく影響します。
- メモリ使用量が小さくなるのでキャッシュ回数が減り実質速くなる
これはHDDへの1回のアクセスが減るとパフォーマンスに大きく影響します。
以前のブログにも書いてますので参考にしてください。
「CPUとメモリとHDD ～チューニングの前に～」
http://uehama.blogspot.com/2010/02/cpuhdd.html
以上のように、パフォーマンスの面で見るとメリットが大きいです。
しかしデメリットもあります
主に保守性に問題があります。まずデバッグが複雑になり、管理（特に修正）が煩雑になります。
対策としては、プレビューで管理する時はそのままにして、テストから本番に上げるタイミングで関数の中だけを難読化するのがおすすめです。JSファイル全体を難読化してしまうと、バージョン管理が相当むずかしくなります。function 毎に分けて難読化することで、それぞれを管理しやすくなりますし、何かあった時のデバッグもしやすくなります。
難読化はルールさえしっかりして、保守性を保つ事ができれば、やった方が断然オトクです。是非試してみて下さい。
それでは。
「難読化」という技術、ご存知でしょうか？
元々はソースコードが読める HTML/JavaScript の世界での流用や悪用、著作権被害などを防ぐために記号化し読みづらくすること、というものでした。ですが、最近は難読化したものを読みやすくするもの等も出てきており、あまり流用防止の為に難読化するというものを見なくなり、著名なライブラリが著作権対策の為に施しているもの以外では使われなくなってきたように思います。
難読化には別の使い道が
この難読化ですが、実はパフォーマンスに結構影響します。
- サイズが小さくなることで読み込み速度があがる（数%）
- 変数名が小さくなるのでローディングが速くなる（数%～数10%）
- メモリ使用量が小さくなるのでキャッシュ回数が減り実質速くなる
などでトータル20～30%速くなることもあります。
- サイズが小さくなることで読み込み速度があがる（数%）
これは想像できますね。サイズが小さくなる事は画像なども同じで表示速度に大きく影響します。
- 変数名が小さくなるのでローディングが速くなる（数%～数10%）
これは分かりますでしょうか？実はこれが一番スピードに影響します。
「a」と「b」を比較するのと、
「abcdefghijklmnopqrstuvwxyz」と「abcdefghijklmnopqrstuvwxyz2」を
比較するのは人間の目でも明らかなように、PCでも速度は大きく違います。
これらは初期ローディング時に自動最適化を行い、2回目以降はキャッシュを利用することで速く実行する技術も採用されてますので、2回目以降はそんなに変わらなくなってますが、初回は大きく影響します。
- メモリ使用量が小さくなるのでキャッシュ回数が減り実質速くなる
これはHDDへの1回のアクセスが減るとパフォーマンスに大きく影響します。
以前のブログにも書いてますので参考にしてください。
「CPUとメモリとHDD ～チューニングの前に～」
http://uehama.blogspot.com/2010/02/cpuhdd.html
以上のように、パフォーマンスの面で見るとメリットが大きいです。
しかしデメリットもあります
主に保守性に問題があります。まずデバッグが複雑になり、管理（特に修正）が煩雑になります。
対策としては、プレビューで管理する時はそのままにして、テストから本番に上げるタイミングで関数の中だけを難読化するのがおすすめです。JSファイル全体を難読化してしまうと、バージョン管理が相当むずかしくなります。function 毎に分けて難読化することで、それぞれを管理しやすくなりますし、何かあった時のデバッグもしやすくなります。
難読化はルールさえしっかりして、保守性を保つ事ができれば、やった方が断然オトクです。是非試してみて下さい。
それでは。
2010年9月6日月曜日
Webサイト高速化技法（３）：きれいなHTMLを書く
Webサイト高速化技法（３）：きれいなHTMLを書く
今回は前回の予告通り、サイトの内部に話を移していきます。
きれいなHTMLとは？
もうお分かりだと思いますが、「きれいなページ」ではなく「きれいなHTML」ですので、見た目の問題ではなく、文法通りにHTMLが書かれているかが問題になります。ブラウザは当然、文法通りに書かれていた方が気持ち良く読めますし、早く読めます。その分表示も早くなります。一度ブラウザの気持ちになって HTML を読んでみる事をおすすめいたします。
たとえば、「レンダリングエンジン」
ブラウザは、レンダリングエンジンという描画エンジンを抱えています。インターネット経由で取得した HTML や CSS の文法を読解し、画面描画の為に、どこに何を書くのか？を判断して描画していきます。
みなさんも今までにいろんなサイトを見てきたと思いますが、それらの表示パターンが何通りかあったのは気付いているのではないでしょうか？
(1) しばらく白い画面が続いて急に画面全体が表示されるパターン
これは古いサイトに良くあるパターンです。テーブルレイアウトを使っているとよくこの現象が出るのですが、テーブルで指定したサイズと画像で指定したサイズ、実際に読み込んだ画像のサイズが違うと全部が計算終わるまで表示が出来なくなり、表示されません。つまり、描画に必要な画像を全て読み終わるまでは真っ白な画面が続く事になります。
こうならないように、テーブルレイアウトは使わずに、画像の width/height 属性も全部に書くようにしてください。
(2) 読み込んだ画像から次々表示されるのでカクカク感があり、読み終わるまでクリックしづらいパターン
このパターンが最近多いのではないでしょうか？読み込んでいる最中に先にページの下部が表示され、そこをクリックしようとした瞬間にその上部が読み込まれ表示されることで、クリックした場所がズレて期待したページではないページへ移動したこともみなさんあると思います。
最近は ajax 技術を使って、それぞれのパーツを別々に読み込ませているサイトが増えてきています。その場合に、それぞれのパーツのサイズが決まってないとカクカク表示され、その度にレンダリングエンジンが再計算をして表示し直す為、それなりにCPUリソースも使います。
できるだけユーザーの為にもカクカク表示させないように、パーツの width/height をしっかり定義しておきましょう。
(3) 全体の枠（レイアウト）が先に表示されて、そこに次々と画像が貼り付けられていくパターン
実はこれが最も早く表示され、かつ、ユーザーにやさしい「きれいなHTML」です。しかし、ここまでこだわっているサイトが少ないのも実情です。上の2パターンは表示が終わるまでレンダリングエンジンが計算しっぱなしで、それなりの負荷も与え、読み終わるまでクリックしづらい状況が続きます。このパターンでは、読み終えた部分から表示され、レンダリングエンジンはレイアウトの再計算をすることが無いので負荷もなく、表示も早く、読み終えてないパーツも alt で説明を入れておく事で、読み込んでいる最中でもズレる事なくクリックしやすいのでユーザーにも優しいです。
対応方法は至って単純です。width/height が必要な項目（画像やテーブルなど）に全て width/height を定義すれば良いのです。そこで、読み終わった画像とのサイズの差が無いように注意が必要ですが、定義しておく事で、表示も負荷も軽くなります。何よりイライラが無くなって人にやさしいサイトになります。
ほかにも注意すべき点
ほかにも、最近気になるページとして「ブラウザのローディングが動いてないのにローディング中」のページがあります。ajax 技術を使っていて、タブのところのグルグルが止まったので、読み込み終了かと思ったら、まだ次から次へ表示される。しかもローディング中かどうか表示されてないので、いつ終わったかが分からない。こういったページが増えてきています。関係者はどこまで読めばクリックできるか分かるので気にならないのかもしれませんが、一般の人が見ると、「終わったの？まだ待った方がいいの？」と悩んでそれがストレスになる事もあります。 ajax とはいえ、ローディング中の場合はその旨表示させる事を義務と考えた方が良いと思います。
今回はレンダリングエンジン（おもに width/height ）を取り上げましたが、他にもいろいろあります。まずはこの辺りから手をつけてみるのも良いかと思い3回目に紹介させていただきました。
4回目は未定です。
それでは。
今回は前回の予告通り、サイトの内部に話を移していきます。
きれいなHTMLとは？
もうお分かりだと思いますが、「きれいなページ」ではなく「きれいなHTML」ですので、見た目の問題ではなく、文法通りにHTMLが書かれているかが問題になります。ブラウザは当然、文法通りに書かれていた方が気持ち良く読めますし、早く読めます。その分表示も早くなります。一度ブラウザの気持ちになって HTML を読んでみる事をおすすめいたします。
たとえば、「レンダリングエンジン」
ブラウザは、レンダリングエンジンという描画エンジンを抱えています。インターネット経由で取得した HTML や CSS の文法を読解し、画面描画の為に、どこに何を書くのか？を判断して描画していきます。
みなさんも今までにいろんなサイトを見てきたと思いますが、それらの表示パターンが何通りかあったのは気付いているのではないでしょうか？
(1) しばらく白い画面が続いて急に画面全体が表示されるパターン
これは古いサイトに良くあるパターンです。テーブルレイアウトを使っているとよくこの現象が出るのですが、テーブルで指定したサイズと画像で指定したサイズ、実際に読み込んだ画像のサイズが違うと全部が計算終わるまで表示が出来なくなり、表示されません。つまり、描画に必要な画像を全て読み終わるまでは真っ白な画面が続く事になります。
こうならないように、テーブルレイアウトは使わずに、画像の width/height 属性も全部に書くようにしてください。
(2) 読み込んだ画像から次々表示されるのでカクカク感があり、読み終わるまでクリックしづらいパターン
このパターンが最近多いのではないでしょうか？読み込んでいる最中に先にページの下部が表示され、そこをクリックしようとした瞬間にその上部が読み込まれ表示されることで、クリックした場所がズレて期待したページではないページへ移動したこともみなさんあると思います。
最近は ajax 技術を使って、それぞれのパーツを別々に読み込ませているサイトが増えてきています。その場合に、それぞれのパーツのサイズが決まってないとカクカク表示され、その度にレンダリングエンジンが再計算をして表示し直す為、それなりにCPUリソースも使います。
できるだけユーザーの為にもカクカク表示させないように、パーツの width/height をしっかり定義しておきましょう。
(3) 全体の枠（レイアウト）が先に表示されて、そこに次々と画像が貼り付けられていくパターン
実はこれが最も早く表示され、かつ、ユーザーにやさしい「きれいなHTML」です。しかし、ここまでこだわっているサイトが少ないのも実情です。上の2パターンは表示が終わるまでレンダリングエンジンが計算しっぱなしで、それなりの負荷も与え、読み終わるまでクリックしづらい状況が続きます。このパターンでは、読み終えた部分から表示され、レンダリングエンジンはレイアウトの再計算をすることが無いので負荷もなく、表示も早く、読み終えてないパーツも alt で説明を入れておく事で、読み込んでいる最中でもズレる事なくクリックしやすいのでユーザーにも優しいです。
対応方法は至って単純です。width/height が必要な項目（画像やテーブルなど）に全て width/height を定義すれば良いのです。そこで、読み終わった画像とのサイズの差が無いように注意が必要ですが、定義しておく事で、表示も負荷も軽くなります。何よりイライラが無くなって人にやさしいサイトになります。
ほかにも注意すべき点
ほかにも、最近気になるページとして「ブラウザのローディングが動いてないのにローディング中」のページがあります。ajax 技術を使っていて、タブのところのグルグルが止まったので、読み込み終了かと思ったら、まだ次から次へ表示される。しかもローディング中かどうか表示されてないので、いつ終わったかが分からない。こういったページが増えてきています。関係者はどこまで読めばクリックできるか分かるので気にならないのかもしれませんが、一般の人が見ると、「終わったの？まだ待った方がいいの？」と悩んでそれがストレスになる事もあります。 ajax とはいえ、ローディング中の場合はその旨表示させる事を義務と考えた方が良いと思います。
今回はレンダリングエンジン（おもに width/height ）を取り上げましたが、他にもいろいろあります。まずはこの辺りから手をつけてみるのも良いかと思い3回目に紹介させていただきました。
4回目は未定です。
それでは。
2010年9月1日水曜日
Webサイト高速化技法（２）：HTTPリクエスト数を減らす
Webサイト高速化技法（２）：HTTPリクエスト数を減らす
これも1回目の「物理的に近い場所に置く」に近い概念となります。
Webサーバーをアメリカに置くとHTTPリクエスト1回でデータは地球を1周します。これがサーバーを近くに置いたとしても数10キロ～数100キロの「旅」は実施されます。この旅の回数を減らすのも大きなポイントです。サーバーの中で処理している時間、クライアントPCの中で処理されてレンダリングエンジンを実行する時間に比べて、データを転送している時間というのは物凄く大きな比重を占めます。また、このリクエスト回数が半分になれば、表示までの時間も半分に近いところまで短縮されます。
どうやってHTTPリクエスト数を減らすか？
単純に画像の数やJSの数を減らせばリクエスト数は減りますが、そうするとWebサイトはやはり地味になってしまいます。サイトのデザインを変えずにリクエスト数を減らす方法はないのでしょうか？
まず、「 @import を減らす」
これは非常に効きます。簡単に説明しますと、CSSファイル内に @import を記述した場合、
1. css ファイルを取得 → 解析 → @import 発見 → 次に読む CSS ファイルを判断
2. @import で記載されていた css ファイルを取得 → 解析・・・・
と、サーバーとクライアントPCの間を2往復します。これらは読み込まないと次のファイル名が分からないので、並行処理はできません。前のファイルを読み込んで解析するまで次のファイルを読み込みに行けません。単純に css ファイル1個の中に書くよりも HTTPリクエストは倍増し、時間も倍増します。極力 @import は使わずに 1つの cssファイル内に書ける分だけ書きましょう。
※注意：何事にも限度があります。あまり長すぎても今度は管理がしづらくなります。管理体系毎に最小の単位に分けて css を記述することをお勧めします。
次に、「 CSS スプライトを使う」
これも非常に有効です。1つの画像の中に何回も流用する画像をパネル状に並べて保存しておくことで、利用時にそれらを css で座標を指定して表示させる部分を切り抜いて使います。ですので、1つのページの中にある数十個の画像を1個にすることで圧倒的に転送時間を短縮させることができます。
※注意：これも同じく限度があります。追加・修正のある画像が中にあると、編集作業や css 定義しなおしが発生して非常に煩雑になってしまいます。次のリニューアルまでほぼ触らないと思われるものだけをピックアップして1枚の画像にするようにしましょう。
あとはひたすら、「ソースの結合」
JSファイルやCSSファイルを小さく数十個記述してあるサイトを良く見ますが、これらは単純にファイルをくっつけて 1枚の長いソースにする事で HTTPリクエストを減らす事ができます。
※注意：これも同じですね。あまり多くを結合してしまうと編集や加筆が非常に煩雑になってしまうことがあります。そうならない為にも、変更しないものだけを抽出することをお勧めいたします。
「 JSファイル圧縮」は？
圧縮という技術もあります。複数の画像やJSファイルを圧縮して1つにし、クライアントPCへロード後に解凍して利用することで、HTTPリクエスト回数を減らしたり、転送（取得）するデータ量を減らして高速化する技術です。しかしこれは最近ではあまり実施している企業はありません。というのも、圧縮してしまうと、ブラウザや利用先でウイルス等の危険性を謳われて取得できない事もある為です。効果はありますが、リスクもありますので、利用の際には細心の注意を払う必要があります。
上記の3つの手段を実施するだけでページの表示時間は大幅にカットされること間違いなしでしょう。前回の（！）の次にこの（２）の「HTTPリクエスト数を減らす」は是非とも実施して見てください。ただし、やりすぎると、編集・修正・プチリニューアル時に大変になりますので、そのあたりも注意しながら実施してください。
次は（３）ですが（３）では内部に話を移していく予定です。
それでは。
これも1回目の「物理的に近い場所に置く」に近い概念となります。
Webサーバーをアメリカに置くとHTTPリクエスト1回でデータは地球を1周します。これがサーバーを近くに置いたとしても数10キロ～数100キロの「旅」は実施されます。この旅の回数を減らすのも大きなポイントです。サーバーの中で処理している時間、クライアントPCの中で処理されてレンダリングエンジンを実行する時間に比べて、データを転送している時間というのは物凄く大きな比重を占めます。また、このリクエスト回数が半分になれば、表示までの時間も半分に近いところまで短縮されます。
どうやってHTTPリクエスト数を減らすか？
単純に画像の数やJSの数を減らせばリクエスト数は減りますが、そうするとWebサイトはやはり地味になってしまいます。サイトのデザインを変えずにリクエスト数を減らす方法はないのでしょうか？
まず、「 @import を減らす」
これは非常に効きます。簡単に説明しますと、CSSファイル内に @import を記述した場合、
1. css ファイルを取得 → 解析 → @import 発見 → 次に読む CSS ファイルを判断
2. @import で記載されていた css ファイルを取得 → 解析・・・・
と、サーバーとクライアントPCの間を2往復します。これらは読み込まないと次のファイル名が分からないので、並行処理はできません。前のファイルを読み込んで解析するまで次のファイルを読み込みに行けません。単純に css ファイル1個の中に書くよりも HTTPリクエストは倍増し、時間も倍増します。極力 @import は使わずに 1つの cssファイル内に書ける分だけ書きましょう。
※注意：何事にも限度があります。あまり長すぎても今度は管理がしづらくなります。管理体系毎に最小の単位に分けて css を記述することをお勧めします。
次に、「 CSS スプライトを使う」
これも非常に有効です。1つの画像の中に何回も流用する画像をパネル状に並べて保存しておくことで、利用時にそれらを css で座標を指定して表示させる部分を切り抜いて使います。ですので、1つのページの中にある数十個の画像を1個にすることで圧倒的に転送時間を短縮させることができます。
※注意：これも同じく限度があります。追加・修正のある画像が中にあると、編集作業や css 定義しなおしが発生して非常に煩雑になってしまいます。次のリニューアルまでほぼ触らないと思われるものだけをピックアップして1枚の画像にするようにしましょう。
あとはひたすら、「ソースの結合」
JSファイルやCSSファイルを小さく数十個記述してあるサイトを良く見ますが、これらは単純にファイルをくっつけて 1枚の長いソースにする事で HTTPリクエストを減らす事ができます。
※注意：これも同じですね。あまり多くを結合してしまうと編集や加筆が非常に煩雑になってしまうことがあります。そうならない為にも、変更しないものだけを抽出することをお勧めいたします。
「 JSファイル圧縮」は？
圧縮という技術もあります。複数の画像やJSファイルを圧縮して1つにし、クライアントPCへロード後に解凍して利用することで、HTTPリクエスト回数を減らしたり、転送（取得）するデータ量を減らして高速化する技術です。しかしこれは最近ではあまり実施している企業はありません。というのも、圧縮してしまうと、ブラウザや利用先でウイルス等の危険性を謳われて取得できない事もある為です。効果はありますが、リスクもありますので、利用の際には細心の注意を払う必要があります。
上記の3つの手段を実施するだけでページの表示時間は大幅にカットされること間違いなしでしょう。前回の（！）の次にこの（２）の「HTTPリクエスト数を減らす」は是非とも実施して見てください。ただし、やりすぎると、編集・修正・プチリニューアル時に大変になりますので、そのあたりも注意しながら実施してください。
次は（３）ですが（３）では内部に話を移していく予定です。
それでは。
2010年8月24日火曜日
Webサイト高速化技法（１）：物理的に近い場所にWebサーバーを置く
今回から新しいシリーズ始めます。
このブログサイトのタイトルにもなっているとおり、Webサイトのパフォーマンスを上げる手法を取り上げていきます。
第１回目からいきなり一番重要な内容を取り上げます。
（１）物理的に近い場所にWebサーバーを置く
どこに近い場所でしょうか？そうです。ユーザーに一番近い場所に置く事が重要です。
数年前、日本がインターネットブームになり始めた頃、まだ日本のデータセンターは高額で、米国の方が安くて回線も太いという理由から米国のデータセンターを借りてWebサーバーを運営している会社が多数ありました。
ですが、今では日本も十分安くなってますし、日本に住むユーザーがメインターゲットであれば当然サーバーは日本に置くべきです。
なぜ近いとパフォーマンスが良いのか？
理由は簡単です。
光でさえ地球1周するのに133msかかります。
光がそれだけかかるのに、通信はルーター等の接続機器を通る段階でルーティング処理が入り、余計に時間がかかります。
また、htmlの仕様上、1回だけの取得では最近の綺麗なWebサイトは表示されません。簡単に良くあるパターンを説明すると、
・html ファイルを取得
・その html ファイルに記載されている css ファイルを取得
・その css ファイルに import で記載されている css ファイルを取得
・その css ファイルに記載されている gif ファイルを取得
Webサーバーが米国にあるとした場合、たったこれだけでも地球を４周します。これらは並列には処理できないので、順次処理され、余計に時間がかかります。
最近の1html内に含まれるファイル数が平均30～50ファイルあるようなページではサーバーの物理的な場所の違いだけで軽く2～3秒の差が出てきます。平均で5～6秒という統計もあります。
ここである統計の記事を紹介します。
・ページの反応速度が0.1秒遅くなると、売上が1%ダウンする。（出典：Amazon調査）
・ページの反応速度が0.5秒遅くなると、アクセス数が20%ダウンする。（出典：Amazon調査）
・表示スピードが1秒遅れると、PVは11%、コンバージョンは7%、顧客満足度は16%ダウンする。（出典：Aberdeen Group調査）
このように、表示の遅れはビジネスに大きなダメージを与えます。
ファイル数を減らすとか、キャッシュサーバーを使うとか、いろいろな手段はありますが、それらよりもまずは、サーバー自体を物理的に近い場所に置くことを最優先にお勧めいたします。携帯ECサイトのいくつかはキャリアに直接専用線を引いて0.1秒にこだわっています。それだけの利益をもたらす場合は十分に投資に値します。
CDNでもいいの？
最近は CDN を使ってグローバル対応している企業も増えてきました。
ゲーム業界やエンターテインメント業界などの世界でコンテンツ販売することで利益を出す構造になりつつあるビジネスでは、これらの反応速度は最重要課題です。こういった企業から順に CDN などを使って世界中どこでも「近い」状況を作っています。最近のAkamai社長のコメントでは、コンテンツビジネスだけでなく、企業サイトもCDN化が進行しているようです。株主総会の動画配信など、ピーク時のアクセス数が想像できない場合などはCDNが特に有効です。
そこまで予算を投下できないという場合は、
amazon EC/2 などの安く使えるクラウド環境を上手く利用する方法もあります。世界中にあるクラウド環境を利用して、リモートで同期を取り、ユーザーのIPアドレスから最も近いサーバーを判断してリダイレクトさせる。それ以降はそのサーバーにアクセスさせるようにすれば、今より2～3秒は早いアクセス速度を実現できます。仮想 CDN ですね。ただ、この場合は同期をとる場合などのセキュリティや運用方法に気を付ける必要があります。同期を取るポートにはIP制限をかけ、一定の時間のみアクセスできるようにする等をして対策を練る事で改ざん予防をすることをお勧めします。
次回、その（２）は・・・、まだ考えてません。近いうちに書いてアップします。
それでは。
このブログサイトのタイトルにもなっているとおり、Webサイトのパフォーマンスを上げる手法を取り上げていきます。
第１回目からいきなり一番重要な内容を取り上げます。
（１）物理的に近い場所にWebサーバーを置く
どこに近い場所でしょうか？そうです。ユーザーに一番近い場所に置く事が重要です。
数年前、日本がインターネットブームになり始めた頃、まだ日本のデータセンターは高額で、米国の方が安くて回線も太いという理由から米国のデータセンターを借りてWebサーバーを運営している会社が多数ありました。
ですが、今では日本も十分安くなってますし、日本に住むユーザーがメインターゲットであれば当然サーバーは日本に置くべきです。
なぜ近いとパフォーマンスが良いのか？
理由は簡単です。
光でさえ地球1周するのに133msかかります。
光がそれだけかかるのに、通信はルーター等の接続機器を通る段階でルーティング処理が入り、余計に時間がかかります。
また、htmlの仕様上、1回だけの取得では最近の綺麗なWebサイトは表示されません。簡単に良くあるパターンを説明すると、
・html ファイルを取得
・その html ファイルに記載されている css ファイルを取得
・その css ファイルに import で記載されている css ファイルを取得
・その css ファイルに記載されている gif ファイルを取得
Webサーバーが米国にあるとした場合、たったこれだけでも地球を４周します。これらは並列には処理できないので、順次処理され、余計に時間がかかります。
最近の1html内に含まれるファイル数が平均30～50ファイルあるようなページではサーバーの物理的な場所の違いだけで軽く2～3秒の差が出てきます。平均で5～6秒という統計もあります。
ここである統計の記事を紹介します。
・ページの反応速度が0.1秒遅くなると、売上が1%ダウンする。（出典：Amazon調査）
・ページの反応速度が0.5秒遅くなると、アクセス数が20%ダウンする。（出典：Amazon調査）
・表示スピードが1秒遅れると、PVは11%、コンバージョンは7%、顧客満足度は16%ダウンする。（出典：Aberdeen Group調査）
このように、表示の遅れはビジネスに大きなダメージを与えます。
ファイル数を減らすとか、キャッシュサーバーを使うとか、いろいろな手段はありますが、それらよりもまずは、サーバー自体を物理的に近い場所に置くことを最優先にお勧めいたします。携帯ECサイトのいくつかはキャリアに直接専用線を引いて0.1秒にこだわっています。それだけの利益をもたらす場合は十分に投資に値します。
CDNでもいいの？
最近は CDN を使ってグローバル対応している企業も増えてきました。
ゲーム業界やエンターテインメント業界などの世界でコンテンツ販売することで利益を出す構造になりつつあるビジネスでは、これらの反応速度は最重要課題です。こういった企業から順に CDN などを使って世界中どこでも「近い」状況を作っています。最近のAkamai社長のコメントでは、コンテンツビジネスだけでなく、企業サイトもCDN化が進行しているようです。株主総会の動画配信など、ピーク時のアクセス数が想像できない場合などはCDNが特に有効です。
そこまで予算を投下できないという場合は、
amazon EC/2 などの安く使えるクラウド環境を上手く利用する方法もあります。世界中にあるクラウド環境を利用して、リモートで同期を取り、ユーザーのIPアドレスから最も近いサーバーを判断してリダイレクトさせる。それ以降はそのサーバーにアクセスさせるようにすれば、今より2～3秒は早いアクセス速度を実現できます。仮想 CDN ですね。ただ、この場合は同期をとる場合などのセキュリティや運用方法に気を付ける必要があります。同期を取るポートにはIP制限をかけ、一定の時間のみアクセスできるようにする等をして対策を練る事で改ざん予防をすることをお勧めします。
次回、その（２）は・・・、まだ考えてません。近いうちに書いてアップします。
それでは。
登録:
投稿 (Atom)