WordPress上に、Cufonで特殊な日本語フォントを搭載した非常に重たいこのウェブサイトの高速化に取り組んで、約1ヶ月。より厳密な軽量化・高速化を徹底して「もうこれ以上は作り方を変えるしかない」というところまでストイックに改良してみたが、その効果を第三者による具体的な数値で確認するために、Googleの新しいサービス Google Page Speed Online で採点し、回線速度やベンチマークも実際の数値を計測してみる。

Page Speed Online ： http://pagespeed.googlelabs.com/
※Firefox のアドオンにある Page Speed は、環境によってスコアが異なることがあるので、こちらのサイトをお勧め。

●方法

1. Google Page Speed Onlineを使ってサイトのスコア（パフォーマンス）を確認し、改善方法を確認する
2. 次に、回線速度を調べ、ベンチマーク測定サイトで、画面表示までにかかる時間を数字で把握する

●結果

Page Speed Onlineのスコア

まず、目安とするために、検索エンジンのGoogleを採点してみた。

なんと100点ではなく99点。「Googleの総合的な Page Speed Score は 99(100点満点)です。」とあった。意外な結果である。しかし高速化は徹底されているらしく「ベストプラクティスを順守しているため～（中略）～読み込み時間の短縮方法はありません。」という評価になっていた。

次に、このサイトを採点。

この1ヶ月くらいの間、コツコツとやってきてホントよかった！と思った96点。さすがに検索欄だけのGoogleに比べると、細かな部分で改善できそうな部分は散見されるが、それでもGoogleと同じ「ベストプラクティスを順守しているため～（中略）～読み込み時間の短縮方法はありません（高速化が徹底されているのでアドバイスはありません）。」という判定だった。

このサイトの各ページをそれぞれ採点してみると、以下のとおりであった。

• トップページ　96/100
• サービス一覧ページ　95/100
• ウェブサイト制作ページ　95/100
• スマートフォン対応ページ　95/100
• サイト運営サポートページ　95/100
• 導入実績ページ　95/100
• 会社案内ページ　95/100
• ラボログページ　95/100
• ラボログの記事の要約一覧ページ　95/100
• ラボログの各記事　94/100
• お問合せページ　95/100

意外と高得点だったので、ついでに、まだ高速化の手順を踏んでいないこのサイトのスマートフォン版の方も採点してみた。

こちらも意外と高得点の 88点で、「ベストプラクティスを順守しているため～（中略）～読み込み時間の短縮方法はありません（高速化が徹底されているのでアドバイスはありません）。」という評価になっていた。

回線速度

下記のサイトで、自社内の回線契約で最も速度の遅い回線を計測してみた結果、以下のとおりだった。

速度.jp ： http://zx.sokudo.jp/

下り受信速度 770kbps 。これは世の中のADSLの契約の中でもかなり遅い速度である（意図的な動作確認用回線）。

ベンチマーク

下記のベンチマーク測定サイトで、画面表示までの時間を計測してみた結果、以下のとおりだった。

WEBWAIT ： http://webwait.com

ベンチマーク（画面表示完了までの平均時間）は、1.78秒。
なお、計測回数は5秒間隔で10回表示させたが、時間帯によってバラつきがあった。

●まとめと考察

PageSpeedOnlineによるこのサイトのトップページのスコアは、96点と高得点だった（検索欄だけのGoogleのスコアが99点）。このことから、デザインを優先（大きい画像を多用したり、情報量を多く）しても、スコアには影響がないことがわかる。

検証に使用した回線は下り受信速度が 770kbpsだったが、ベンチマーク（画面表示完了までの平均時間）は 1.78秒であった。簡単に表現すると、すごく遅い回線でもページの画面表示の完了までの時間が2秒以下。すなわち、このサイトの見出しなどで使用しているCufonによる日本語フォントの表示も、高速化を徹底する場合は現実的な方法と考えてもよいだろう。

スマートフォン版サイトは特に高速化の調整をしていなかったが、意外にもGoogleの評価で100点中88点だった。
jQueryMobileは開発効率がよかったが、高速化という観点からはこれ以上の改善が難しい状態にあり、構造的に若干不利なフレームワークかもしれない。また、各ソーシャルネットワークのパーツは高速化を最優先と考える場合、できるだけ設置しない方がよいだろう。

SEO対策として行ったのはsitemap.xmlの送信程度でh1タグすらまだ設定していない…要はなにも行っていない状態だが、Googleも公表していたとおり、高速化だけで検索結果の順位がかなり上昇した（近日検証予定）。

なお、Page Speedのスコアを基準とすれば、回線速度やベンチマークを測定する必要はない（確認のために実施）。

●今後の課題

• Google Page Speed Onlineで指摘されている項目で可能なものは改善する
• Facebookページのコンテンツに対しても高速化を行ってみる
• 高速化と順位変動の関係性をつかむため、特定のキーワードで検索結果の分析を行う
• 動画を含めたサイトマップファイルを作成し、検索結果で表示されるコンテンツの順位を調整する
• 今後リリース予定のGoogleの自動高速化サービス*によって高速化されるサイトとスコアを比較してみる

*Google Page Speed Service :
http://googlewebmastercentral.blogspot.com/2011/07/page-speed-service-web-performance.html

*デジタル･ソリューションズのFacebookページ :
http://www.facebook.com/dgsl.co.jp

2011年6月22日にウェブサイトをリニューアルしたので、この1ヶ月間でのGoogle Analyticsのデータから読み取れることを総括し、やらなくていいことを決め、やるべきことを明確にすることで、来月のサイト運営の指針とする。

●方法

Google Analyticsの「過去と比較」オプションを使って、データから理解できたことを箇条書きにする。

●結果

Google Analyticsのデータを分析した結果、以下のとおりであった。

• 1ヶ月（リニューアル）前と比べてみると、訪問者数が6倍、ページビュー数は15倍となった
• サイト全体のページ数は減少させたが、リニューアル前の1.3倍のページを閲覧してもらえるようになった
• 直帰率が改善され、サイトの平均滞在時間が5倍以上となった
• 新規訪問の割合は4割以上減少、スマートフォンユーザーは15倍以上の増加となった
• ユーザーの環境をまとめると、PCユーザーは全体の72%、スマートフォンユーザーは全体の28%の割合
• 最も多かったのはWindowsでChromeを利用してる人（28.7%）、次にiPhoneユーザー（22.0%）
• スマートフォン端末ごとの内訳は、iPhone（+2900%）、Android（+1080%）、iPad（+200%）、iPod（+600%）
• InternetExplorerユーザーは全体の9%で、そのうちIE8ユーザーが全体の5%、IE6ユーザーは全体の0.1%であった
• フィーチャー・フォン（いわゆるガラケー）からのアクセスはなかった（0%）
• 世界24ヶ国からアクセスがあり、英語環境のPCユーザーが大幅に増加（+1883%）した
• 流入経路としては、Googleが一番多く(20%)、ついでFacebook(13%)であった
• 検索エンジンの種別では、Googleが91%、Yahooが5%、@Searchが3%、Bingが1%であった

分析にもとづく決定事項

上記の箇条書きから、まず、以下の「すぐに（もしくは今後？）やらなくていいことリスト」を決定した。

1. フィーチャー・フォン（いわゆるガラケー）対応は行わない
2. IEのレガシー（IE6、IE7などの旧バージョン）対応は行わない
3. Bing対策は行わない

●まとめ

このウェブサイトのリニューアルはデータから判断すると比較的良好な結果であった。スマートフォンユーザーが爆発的に増加、とくにiPhoneユーザーが圧倒的で、PCユーザーで一番多い閲覧環境に迫っている（運用途中で、思わずスマートフォン対応サイトを作成したほどだった）。リニューアル後のこのサイトはもともとIE対応ではなかったが、InternetExplorerユーザーの大幅な減少傾向に助けられた。同時にIEのレガシー対応はほぼ必要でないこともわかった。フィーチャー･フォン（ガラケー）対応ではなかったが、そもそもアクセスしてくるユーザー自体が存在していないことがわかった。検索エンジンはGoogleが圧倒的（おそらくYahoo、@SearchもGoogleと同じアルゴリズム）なので、アルゴリズムの異なるBing対策は行わないことにした。ソーシャルネットワークのトラッキングの分析は、また別途実施してみたい。

今後の課題と目標

以上のアクセス解析の分析と総括から、以下の課題と目標を決定した

• 新規訪問数を増やす方法を考え、実行する
• いくつかの分岐方法を検討し、英語版を作成してみる
• ページビュー数は月間1万ページ以上をきちんとクリアする

※Google Analyticsのデータはウェブサイトごとにまったく異なることが多いので、この分析結果が必ずしもすべてのウェブサイトにあてはまるものではありません。

●背景と目的

YouTubeの3D Video Creator（3D 動画作成ツール）というサイトを発見。2つのカメラがあれば、動画を3Dに変換できるという。しかも、裸眼でも見えるらしい。…ということで、さっそくやってみました。

YouTube 3D Video Creator

http://www.youtube.com/editor_3d

●方法

1. 小型木製イーゼルにiPhone2台を固定し、同時に撮影する。
2. YouTubeのチャンネルに動画をアップロードし、3D Video Creatorで3Dに合成する。

●結果

iPhone2台で以下のような動画を作成することができた。また、キャプション(CCボタン)をつけることもできた。
日・英で字幕を付けてみたところ「キャプションを翻訳BETA」というメニューで51カ国語翻訳に対応している模様。

※実際に作成した裸眼用3D動画（YouTube上のものをサイズを変えて貼り付けています）

ここにはYouTubeと同じ動画を貼り付けているので、再生ボタンを押した時に上の画像と同じ画面になっていない場合、YouTubeプレイヤー上で下記の「3D」の設定が必要。ただし、Windows XPのChromeだけうまく動作しない（後述）ので、Windows XPの方はFirefox最新バージョンで試してみてください。

YouTubeプレイヤーの裸眼用3D表示の設定方法

1. 「3D」ボタンを押し、「他のオプション…」を選ぶ

2. 「3Dデバイスなしで動画を再生」をクリック」

3.「うまく表示されました。動画に戻ります。」ボタンを押して動画に戻る。

3D動画を浮き出させるコツとしては、下記の要領で。

どうしても●がひとつに重ならない場合、画面から1mくらい離れてみたりするとうまくいくことが多い。

●考察

作成した3D動画は、再生環境によって以下のような表示の違いが存在した。

裸眼3D用の焦点がちゃんと表示されるOSとブラウザのバージョン

• Windows Vista Chrome(12.0)
• Windows Vista Firefox(3.6)
• Windows XP Firefox(5.0)
• Macintosh OS X Safari(4.1)
• Macintosh OS X Firefox(3.6)

※これが想定していた画面の表示

焦点が表示されず、アスペクト(縦横)比が変更されてしまう環境

• Windows XP Chrome(12.0)
• iPhone4 SAFARI　(画面下部のメニューも表示されない)
• iPad SAFARI　(画面下部のメニューも表示されない)

※想定していなかった画面の表示（縦横比は異なってしまうがこちらの方が浮き出やすい）

なお、アナグリフ(赤/シアンなどの2色に分解された映像)用に3Dメガネも作ってみたが、裸眼3Dより焦点を合わせるのが難しかった。仮説だが、アナグリフ3Dと裸眼3Dではカメラと被写体までの距離が微妙に異なるのではないかと推測している。なお、Androidの3D対応モデルでは、特に設定をしなくても3D表示となるらしい（未検証）。　

今後はCCボタンを押すと表示される「キャプションを翻訳BETA」メニュー（51カ国語への自動翻訳）の検証も時間を作ってやっておきたい。

参考：
今回の3D動画に関する基礎知識は、日本語のウィキペディアにある「3次元ディスプレイ(autostereoscopic display)」ではなく、英語のウィキペディアにある「Stereoscopy(いわゆる、3D画像の原点)」の方を参考とした（出典がもっとも古くわかりやすかったため）。

3D display Wikipedia （日本語ページ・編集中、2010年が最古の出典）
http://ja.wikipedia.org/wiki/3次元ディスプレイ

Stereoscopy Wikipedia（日本語ページなし、1860年が最古の出典）
http://en.wikipedia.org/wiki/Stereoscopy

YouTubeで以前から開発されていた自動音声認識＋多言語字幕が、いつの間にか使えるようになっていたのでさっそくやってみました。

※こちらは画像です。クリックするとYouTubeが開きます。

参考記事：
動画の音声が自動的に日本語字幕に YouTube自動キャプション機能が日本語対応
http://www.itmedia.co.jp/news/articles/1107/15/news080.html

●方法

1.サンプルの動画を作成する。

Xtranormal Movie MakerというYouTubeの新しいサービスを使って簡単な動画を作成する。今回は検証用に英語で「Hi, I’m Naked John（裸のジョン）」という簡単なお笑い動画を作成した。

Xtranormal Movie Maker

http://www.xtranormal.com/

2.音声認識機能を使ってみる。

YouTubeのチャンネルにアップロードし、管理画面から自動作成。

※ドイツ語、英語、Spanish(Spain)、フランス語、日本語という欄は自動作成ではないキャプション用データ（.sbv）

3.自動翻訳の精度を試してみる。

公開された動画の「CC」ボタンから他の言語を選択し、英語に翻訳する。検証にはGoogle翻訳を使用。

※CCボタン >> キャプションを翻訳^BETA >> 翻訳したい言語を選んで、OK

Google 翻訳

（YouTubeで自動翻訳した言語→英語、で誤差を確認）
http://translate.google.co.jp/

●結果

• 自動音声認識は、YouTubeのサービスによって作成されたCGキャラクターの音声に対しても70～80%の精度だった。
• その結果、作成されたキャプション用のデータ（.sbv）をダウンロードして編集（要は入力）した。
• 自動翻訳は、日本語への翻訳を除いてまずまずの翻訳精度だったが、日本語の字幕は別途作成が必要だった。
• 結局、英語のキャプションから日本語、スペイン語、フランス語、ドイツ語の合計5カ国のキャプションを作成した。
• 自動翻訳で翻訳可能な言語は以下の51種類で、日本語を除き、英語から翻訳すればまずまずの翻訳内容だった。

1. アイスランド語
2. アイルランド語
3. アフリカーンス語
4. アラビア語
5. アルバニア語
6. イタリア語
7. インディッシュ語
8. インドネシア語
9. ウェールズ語
10. ウクライナ語
11. エストニア語
12. オランダ語
13. カタロニア語
14. ガリシア語
15. ギリシャ語
16. クロアチア語
17. スウェーデン語
18. スペイン語
19. スロバキア語
20. スワヒリ語
21. セルビア語
22. タイ語
23. チェコ語
24. デンマーク語
25. トルコ語
26. ドイツ語
27. ノルウェー語
28. ハイチ語
29. ハンガリー語
30. ヒンディー語
31. フィリピノ語
32. フィンランド語
33. フランス語
34. ブルガリア語
35. ヘブライ語
36. ベトナム語
37. ベラルーシ語
38. ペルシア語
39. ポルトガル語
40. マケドニア語
41. マルタ語
42. マレー語
43. ラトビア語
44. リトアニア語
45. ルーマニア語
46. ロシア語
47. 中国語（簡体字）
48. 中国語（繁体字）
49. 日本語
50. 英語
51. 韓国語

●まとめ

• 自動音声認識によって作成されるファイルは、映像のタイムキーパーとしての役割としては十分機能する。
• 現時点では、セリフに関しては、タイムラインに沿った表示の確認や文言の修正（ダウンロードして入力）が必要。
• 英語→日本語以外の言語への翻訳は割とうまくいく様子だが、日本語への翻訳は…結局、入力し直すことになった。
• 「キャプションを翻訳」メニューを使用しない（必要な言語のキャプションを用意しておく）方が動画の再生がスムーズ。
• 「その他の設定…」メニューから字幕のフォント（文字の種類）を選べたりするところは遊び心があってよいと思った。
• 日本語のキャプションのほか（自動翻訳でない）英語のキャプションがあれば多言語対応の字幕になる。
• iPhone、iPadではYouTubeのプレイヤー下部が表示されない。Androidは未検証。

●背景と目的

GoogleAnalyticsの画面を眺めていたら、このサイトにこの1ヶ月で約25%（4人に1人の割合）の人がスマートフォンでアクセスしていたことを発見。「むむ、なんだか増えたなぁ…」と思って、ちょっと調べてみると、たしかにスマートフォンの急速な普及が進んでいるらしい。

総務省「通信利用動向調査」結果、ネット利用者数は9408万人で普及率78.0％

http://web-tan.forum.impressrd.jp/n/2010/04/29/7924

拡大するスマートフォン市場！2015年には年間3,550万台に

http://headlines.yahoo.co.jp/hl?a=20110703-00000007-rbb-sci

国内のインターネットユーザーが2009年の時点で9408万人、スマートフォンユーザーが2010年度の時点で705万人。ここ数年はインターネットの人口の約10%がスマートフォンユーザーだが、2015年には30%を超える計算になる。

このサイトのスマートフォンユーザーのアクセス数の実態からの考えると、上記の記事よりもうすこし早いペースでスマートフォンユーザーが増えているように思う。私たち自身もiPhone、iPadユーザーなので、このサイトをスマートフォン対応サイトに変更してみることにした。もちろん、スマートフォン向けのサイトも高速化（軽量化）を行った。

●方針

あくまでも検証用のプロトタイプなので、なるべく工数を少なくした。ポイントは以下のとおり。

• PC版(wordpress)のサイトの内容をそのまま転用し、PC版とほぼ同じ構成とする
• 分岐のプラグインだけを使用し、スマートフォン向けのテンプレート型プラグインは使用しない
• jQuery mobileによるインターフェースを実装（…というか、検証）する
• gzip圧縮による高速化（軽量化）の徹底する
• 実機やエミュレーターでの検証を行う

その他、細かい調整になるが、以下のようなことも行った。

• トップページのスライダーをスマートフォン用に軽量化したものに変更する
• 導入実績のページを、PC版のズームではなく、フリック（横にスライド）式に変更する
• iPhoneでは、ホーム画面に追加するとアイコンが現れるような設定とする
• ホーム画面に追加されたアイコンから起動した際は、フルスクリーン表示モードになる設定とする

●検証

それぞれの動作確認の結果は以下のとおり。

実機による動作確認の結果

　○ SoftBank iPhone4
　○ SoftBank iPad　（現在はPC版に転送されるよう設定）
　○ SoftBank GALAPAGOS 003SH
　○ SoftBank QUOS PHONE 006SH
　○ SoftBank Disney mobile DM00pSH

エミュレーターによる動作確認の結果

Androidは機種があまりにも多かったので、下記のものだけを検証した。

　○ Docomo Xperia SO-01B
　○ Docomo Xperia arc SO-01C
　○ Docomo MEDIAS N-04C
　○ au IS01
　○ au IS03
　○ au IS11SH
　○ SoftBank iPhone3G
　○ SoftBank HTC Desire 001HT
　○ SoftBank GALAPAGOS 005SH

　検証で使用したエミュレーター：Fire Mobile Simulator

●結果

スマートフォンでアクセスすると、以下のスマートフォン版サイトが表示されるようになった。

なお、スマートフォン向けサイトの公開にあたっては、以下の点にも注意した。

• 最下部のフッターは、PC版のソーシャルボタンと連動させた（「ツイートする」と「いいね！」の数をPC版と同じに）
• ブログ記事は、個別にシェアできるように変更した（新しくLinkedInのシェアボタンも設置）
• スマートフォンのGoogleマップ、電話、メールなどの使いやすさをそのまま生かすようにした

●まとめ

• jQuery mobileによる実装は、iPhoneとAndroidの双方にそのまま対応できるという点では便利
• 従来の携帯電話向けサイトに比べて、キャリアや機種によって振り回されることはなかった
• スマートタブレットまで考慮するのであれば、media queryによる制御の方が合理的（かなと思う）

じつは、リニューアル後、アクセス数やページビュー数が急激に増加。これを受けて、ウェブサーバーの負荷の軽減とウェブサイト自体の表示速度を向上させること（私たちにできるちょっとした努力）で、インターネット全体のささやかな「節電」につながればと考え、その最初のステップとしての「サイトの軽量化（gzip圧縮）」の取り組みを始めました。

●背景と状況、そして目的

海外ではかなり前から常識になっている、ウェブサイトの高速化に取り組んでみることにした。
背景としては、大きく以下の3つ。

• Googleは検索結果の評価にウェブサイトの「表示速度」を加味する、と発表している。
• Googleのウェブマスターツールでも「サイトのパフォーマンス」という画面がある。
• GoogleAnalyticsの新バージョンでも「サイトの速度」というメニューが用意されている。

このサイトの置かれている状況としては、以下のとおり。

• 希望するキーワードでの検索結果が上位なので、SEOチューニングは急務でない（予想外）。
• Cufonでレンダリングしている見出しなどの日本語フォントが重い（かなり無茶だった）。
• gzip圧縮は本やブログに掲載されているような方法ではうまく動作しない（ことが多かった）。

目的としては、ひとまず以下の3つ。

• サーバーの負荷、サイト利用者のパソコンの負荷を軽減させる。
• できるだけ多くのブラウザで、gzip圧縮を確実に動作させる。
• 実際にどのくらいの圧縮効率なのかを数字で把握する。

●調査

書籍やブログで紹介されていた方法をここ数年、いろんなサーバーでひとつひとつ検証していったが、ユーザー側からの検証（自分以外の環境からのテスト）という客観的な視点が落ちている記事が多く、いずれもブラウザごとに挙動が異なる（あるブラウザではgzipを展開、あるブラウザではgzipを無視する）といった不安定な結果となる方法ばかりだった。

いろいろと調べていくうちに、ブラウザの挙動の問題については、あのGoogleでさえ悩んでいたことを知った。簡単ではないのだ。この問題について、下記の海外のブログ記事によって初めて理解することができた。

gzip圧縮を設定するだけでは足りないこと

http://velocityconf.com/velocity2009/public/schedule/detail/9072

要約すると「gzip圧縮をただ設定しただけでは、すべてのブラウザでうまく動作しない」ということだ。
この問題は、長い間、海外では議論され、Googleのアンディ氏が解決方法を考案してたらしい。

強制的なgzip圧縮

http://velocityconf.com/velocity2010/public/schedule/detail/14334

要約すると「gzip圧縮を徹底するには、かなり強制的な方法が必要だ」ということだ。
結局、このGoogleのスタッフの考え出した方法によって、現在のGoogleのスピードが達成されており、このサイトもgzip圧縮がブラウザによって実行されないという問題を解決することができた。（じつは、このブラウザで起こったり起こらなかったりする謎の現象そのものを理解するまでに1年くらいかかった）

●結果

すべてのJavaScriptファイルとCSSファイルの理論上の圧縮率は以下のとおり。（クリックすると拡大できます）

ウェブサイトの高速化 理論上の圧縮率（当社調べ）

実際のオンラインでのgzip圧縮のテストの結果は以下のとおり。（クリックすると拡大できます）

ウェブサイトの高速化 実際のオンライン上の圧縮率

gzip圧縮のテストサイト：GID Network – gzip test tool

理論上の値も、実際のオンライン上の値も、ほぼ同じ70%のデータ転送量の削減に成功。画面の表示速度も体感でかなり向上した（…ように思っている）。ちなみに、WordPressの公式サイトに載っていた.htaccessの記述は私のサーバーでは動作しなかったので、.htaccessファイルをほんの数行だけ記述した。（サーバーによって.htaccessの記述は異なるはずなので、具体的な記述内容は非公開）。また、Wordpressのさまざまなgzip圧縮の（自動的に圧縮できます的な）プラグインはサーバーに負荷をかけるようなので使用せず、gzip圧縮したものを記述した.htaccessファイルで展開し、PHP以外はサーバー上で圧縮しない方法によって軽量化を行うことにした。

●まとめ

今回のウェブサイト高速化（おもにgzip圧縮による軽量化）について、まとめると以下のことが達成できた。

• gzip圧縮を徹底するだけで、約70%のデータ容量を削減できた。
• Yslowのスコアは全体で「C（70～80点台）」から「B（80～90点台）」へと評価が向上した。
• Windows Vista、XP、MacintoshのChromeおよびFirefox、iPhoneのSAFARI上でgzip圧縮が動作。

個人的な感想としては、以下のとおり。

• ベンチマーク（速度）は計測していないが、体感でかなり表示が速くなった。
• Cufonで日本語フォントを扱う場合、フォントのデータ容量が大きいのでgzip圧縮は必須。
• 負荷の少ないgzip圧縮をきちんと動作させるには、意外と地道な手作業や動作確認が必要。

●今後の課題

「どこまで高速化を追求するのか」という程度問題であるが、じつは、まだ以下のような改良できる点がある。
それぞれの作業は時間がかかる可能性は高いが、いずれ着手しようと思っている。

• ソーシャル関連のパーツは、表示速度という観点から見ると非常にマイナス。記述の改良が必要。
• WordPressはDBからデータを吐き出すので、軽量化しても表示が遅い。なんらかの工夫が必要。
• コンポーネント化されているJavaScriptファイルやCSSファイルを1つにまとめる。
• CSSスプライトを使って、デザイン上のグラフィックすべてを1つにまとめる。
• すべての画像をAmazonS3からのダウンロードに変更する。
• 静的なファイルの有効期限を設定する。

参考：
Google Code How gzip compression works

8PMD83YXBQQB

●背景

いろいろと新しい技術を搭載し、いわばひとつの実験台としてリニューアルした当サイト。今後実施予定のSEOチューニングの目安とするために、現時点（チューニングしてない状態）での主要な検索エンジンでの順位を調べてみた。

今回の検証にあたっての前提条件は以下のとおり。

• 2011年6/22にリニューアルサイトを公開。SEOは行わず、約1週間放置した状態。
• WordPressを使用。特別なプラグインはインストールしていない。
• HTML5、CSS3、jQueryによるインターフェースの実装とソーシャルパーツの積極的な採用。
• hxタグは、日本語フォントをCufonでCanvas上にレンダリング。
• トップページにはh1タグを設定していない（すっかり忘れてた）。
• 各ページの原稿執筆時にも特別なキーワード対策は行っていない。
• リニューアル後に検索エンジンへの登録は行っていない。
• リニューアル後にsitemap.xmlやrobot.txtの設定はしていない。
• リニューアル後に被リンクはまったく増やしていない。
• リニューアル後にプレスリリースやPPC広告も出していない。

簡単に言うと、技術的にチャレンジしたいことがたくさんあったので、SEO対策はリニューアルサイトを公開してから少しずつ、時間をかけて取り組もうと考えていた。

●方法

主要な検索エンジンで、以下の複合キーワードで検索し、現時点の検索結果での順位を確認する。

• 「所沢 制作 会社 ウェブ」
• 「所沢 制作 会社 web」
• 「所沢 制作 会社」

検索結果の調査にあたっての注意点としては、以下の2点。

• ブラウザのキャッシュ（公開してからの1週間分）をクリアする
• Google、Yahoo、MSNからはログアウトした状態で検索する

簡単に言うと、環境に依存しない（パーソナライズドされていない）検索結果となるようできるだけ気をつけた。

●結果

2011年7/2の時点での主要な検索エンジンの検索結果ページにおける順位は、以下のとおり（画像はクリックで拡大できます）。

Google

検索キーワード「所沢 制作 会社 ウェブ」

検索キーワード「所沢 制作 会社 web」

検索キーワード「所沢 制作 会社」

Yahoo! JAPAN

検索キーワード「所沢 制作 会社 ウェブ」

検索キーワード「所沢 制作 会社 web」

検索キーワード「所沢 制作 会社」

Bing

検索キーワード「所沢 制作 会社 ウェブ」

検索キーワード「所沢 制作 会社 web」

検索キーワード「所沢 制作 会社」

Google（iPhone）

検索キーワード「所沢 制作 会社 ウェブ」
検索キーワード「所沢 制作 会社 web」
検索キーワード「所沢 制作 会社」

●まとめ

これらの結果から、GoogleとYahoo!の検索アルゴリズムが同一であることがわかる。BingはGoogleやYahooとほぼ同じだが、ミドルキーワードに関して、若干異なる評価軸を持っていることもわかる。また、どういう仕組みなのかはわからないが、iPhoneのGoogleではなぜかスマートフォンに関するページが最上位に現れる。

偶然であるが、公開してから検索エンジン向けのチューニングに取り組もうと思っていたので、SEO対策におけるこれまでの常識は、まったく検索結果の順位に影響していないこともわかった。

よく書籍やブログに書いてあるSEO対策と、実際に上位に位置するサイトの現状を比較してみると、以下のとおりである。

• ページ数は多いほうがよい　⇔　現時点で20ページもない
• ページごとにキーワードやディスクリプションを設定　⇔　全ページ同じ設定にしていた
• 検索エンジンに登録する　⇔　計測時点ではまったく登録してない
• SEO対策のプラグインを入れる　⇔　プラグインはほとんど入っていない
• h1タグはきちんと設定する　⇔　トップページではh1を入れていない（すっかり忘れてた）
• キーワードアドバイスツールを使う　⇔　まったく使っていない
• 関連キーワードを見つける　⇔　まったく探していない
• 重要な箇所には強調タグをつける　⇔　まったくやっていない
• 略称や住所には論理タグをつける　⇔　まったくやっていない
• アンカーテキストにはキーワードを入れる　⇔　まったくやっていない
• パンくずリストを用意する　⇔　まったく入れていない
• 高速化されたページの方が有利　⇔　まだやっていない
• スマートフォン向けのSEO対策が必要　⇔　まったく考慮していない
• 新しいドメインの方が有利　⇔　2004年に取得した古いドメインをそのまま使っている
• W3Cに準拠したHTMLでマークアップする　⇔　FacebookやGoogle+1のコードはW3C準拠ではない
• SEO対策は時間がかかるので長期的に取り組む　⇔　リニューアル公開から約1週間放置。対策は皆無。

あくまでも現時点での仮説に過ぎないが、書籍やブログで紹介されているSEO対策を一切行わずに、かなり良好な結果が得られたのは、新しい構造のウェブサイトが評価されたから？と勝手に推測している。

GoogleAnalyticsの新しいバージョンでは、ソーシャルのトラッキングのほかに、ウェブサイトの評価に「表示速度」も導入するようなので、技術的にちょっと高度な取り組みになるが、今後はウェブサイトの「高速化」に取り組むつもりである。

私自身は、検索結果の順位よりも、使いやすさやわかりやすさの方がずっと大切なことだと考えている。

※検索結果はいずれも2011年7月2日時点のもので、計測日時が異なる場合、画像の検索結果とは内容が異なる可能性があります（私たちも日々チューニングしてたりします）。

8PMD83YXBQQB