Webサイト

WEBサイトのページ表示速度の高速化 | SEOとセキュリティの観点から

  • このエントリーをはてなブックマークに追加
  • Pocket
  • LINEで送る
security_1069

あなたのWebサイトの表示速度は早いですか?

最新の研究では、Webサイトの表示に3秒以上かかると、訪問者のおよそ半分が表示を諦めるという結果が報告されています。

また、表示速度によってアクセス数が変化するという報告もあります。

Webサイトの高速化ができていれば、獲得できたはずの訪問者を逃すことはなかったかもしれません。

ここでは、大切な訪問者を逃さないために役立つWebサイトの高速化テクニックを紹介いたします。

WEBサイトを高速化する3つのメリット

security_692

検索結果の上位に上がりやすくなる

ユーザーの利便性は検索順位にも影響し、売上にもつながります。
ページスピードが早ければ訪問者もより多くの情報を見ることになりサイトの評価も高まります。

閲覧のストレスをなくし、よりページを見てもらえる。

逃していた25%のユーザーがよりページを閲覧し、興味を持つようになります。
400人来ていたら100人のユーザーを取り逃がしていた計算です。
購入率が1%で1人あたりの売上が10000円の場合、売上は理論上1.33倍に上がります。

【改善前】
400人-100人(400×25%)×0.01=3×10000円=30000円

【改善後】
400人×0.01=4×10000円=40000円

再訪問するユーザーも増え、リピーターが多くなる

逃していた61%の訪問者がまたこのサイトを見たいと訪問するようになります。
リピートが増えればその分だけ売上も上る可能性が高まります。

SEO対策編

security_689

検索エンジン(Google)も、「ユーザーの利便性」を重視しサイトの順位を決定しているため、よりユーザーにいいサイト、表示が遅いサイトは評価を下げられ、表示が速いサイトは、評価の高いサイトであると加点するようになりました。

実際にGoogleは2010年4月、正式に「ページの表示速度が正式に順位決定に関係する」と発表し、サイトの表示速度は、検索結果の上位を目指すための要素の1つとして、重要な項目になりました。

海外で行われた調査により、高速化で売り上げが向上した実例が多数あります。


  • 価格比較サイト「Shopzilla」:6秒から1.2秒に高速化することによって12.0%の売上向上
  • 検索サイト「Bing」:2.0秒高速化されるごとに5.0%の売上向上
  • ネット通販サイト「Amazon.com」:0.1秒高速化されるごとに、1.0%の売上向上

セキュリティ対策編

security_690

セキュリティの観点からサーバー側に処理の問題で影響がでます。
表示速度が遅いのは回線そのものが遅いかリソースが圧迫されて情報処理が遅いかページのボリュームがあって遅いかの3つのいずれかもしくは複数の要素が考えられます。

セキュリティで遅い原因としてサーバーは常時DDos攻撃を受けるなどの攻撃に晒されています。
最近はDDoSやDoS、スローDoSといって攻撃が一般ユーザーを模して攻撃してくるのでログを見たところでなかなか判別できない攻撃があったりします。

スローDoSの攻撃で常々圧迫されて遅いという可能性もあって特にレンタルサーバー1台を狙うと共有で使っている数100のサイトが互いにリソースを食い合ってて攻撃されて遅くなっていることが往々にしてあります。

対象方法としてはDDoSの場合はIPドロップ(アクセス拒否)しか存在しません。いわゆる外部からの攻撃に関して表示速度が遅くなっている可能性があるので「セキュアログ」「アクセスログ」を確認しましょう。

セキュアログ

サーバーにアクセスした時の特定のポートや特定の穴に対してログが溜まっていくログのためここに攻撃しても遅くなることは少なくあまりわからない。

アクセスログ

不正な文字列など(例:X87%・・・とか)サイトにおいて当然つかわないログまたは使っていないディレクトリに対するアクセスなど大量に行われるとリソースが足りなくなり表示速度が遅くなる原因となるため不正なアクセスがあった場合に404ページに誘導するなりIPをドロップするなりして対応する方法がある。

フロントエンド側の高速化

html、CSS、javascriptの軽量化

読み込むCSSファイルは可能な限り少なくすることが有効です。
例えば短いCSSはHTMLファイルに埋め込むことや外部ファイル化でもデータの圧縮となり削減が可能となります。

またjavascriptはソースの~タグ内ではなく、タグの直前に記述することで処理時間を早くすることが可能です。

編集しやすいようにと改行を挿入するなど見た目を良くするため余白を入れることがほとんどですが、余計な空白やコメントはファイルサイズが大きくなる原因です。

画像ファイルの最適化

CSSやjavascriptよりも効果が出やすいのが画像の最適化です。
画像を圧縮すると比例して画質が悪くなることも考えられますが、劣化させることなく画像ファイルを軽量化するサービスも多数あります。
それによって読み込み速度の向上につながります。サムネイル画像を使うのも効果的です。

ブラウザキャシュの活用

「.htaccess」を設定するのが一般的な方法です。
ここで注意が必要なのは「.htaccess」の設定を間違えるとサイトが表示されなくなることや、誤った記述をするとサーバー負荷が高くなる不具合が生じる可能性があります。

CSSスプライトを利用する

サイトの読み込み速度を高速化するのに最近多くのサイトで導入されています。
読み込み速度が速くなるメリットはありますが更新が大変になったりデメリットもありますのでサイトの目的にそった利用をしていきましょう。

amazonやfacebook、youtubeなどの大手サイトでは導入されていますが、Web製作者からすれば作業が増えるのでバランスを考えましょう。

CSSスプライトのメリット

  • HTTPリクエストの回数が減りサイトの高速化ができる
  • 画像ファイルを減らせる

CSSスプライトのデメリット

  • SEO対策では設定するalt属性が使えない
  • 画像を1つにまとめることの準備が増える

CSSセレクタのパフォーマンス

ブラウザはセレクタを右から左へ読んでいきます。表示速度を早くするためには

  • ユニバーサルセレクタは控える
  • 可能な限りidやclassを設定し、要素名はつけない
  • 子孫セレクタは最低限の利用とする
  • リンク以外に:hoverを利用しない

などがあります。

JavaScript/CSSの排除

Googleは以下の2通りの解決方法を推奨しています。

  • 小さな JavaScript をインライン化する
  • JavaScript の読み込みを遅らせる

フロントエンド高速化のデメリット

Googleの「PageSpeed Insights」というツールを使用すれば、表面的な高速化をすることはできるでしょう。
しかし、このツールを使った結果、実際に高速化できるのは全体の10%未満です。

つまり、表面上だけしか最適化できていないということです。
車で例えるならば、見える部分はカスタムしたものの、エンジン周りなど「見えない部分」が最適化できていないのです。
体感速度として実感するのは難しいでしょう。

内面部分の高速化とは、この「車のエンジン周り」にあたるものです。
車でいうと整備士よりで技術的なことになりますが、高速化の手法はバラバラです。

仕組みもたいへん複雑で、ある程度以上の専門的な知識が必須になります。
次に内面部分、つまりバックエンドの高速化を紹介致します。

バックエンド側の高速化

OS/ミドルウェアの最適化

基本的にはMySQLでもPHPでもバージョンを新しくすればするほど性能は良くなっているため、最新のバージョンにするイコール高速化することができます。

クラスタ化するMySQL Clusterやフレームワークも最新のバージョンのほうが過去のバージョンよりも優れている可能性が高いので常に最新バージョンに保つことで高速化に繋がります。

最適化実績

security_694

自社サイト(ブログを使ったオウンドメディア)の改善例

調査前の相談内容

アクセスの割にサイトのレスポンスが重く、その原因がわからない。
安定的に運用したいが、現在の設備構成に過不足があるのかを調査してほしい。

施策内容

  • ミドルウェアの入れ替え
  • 不要なサービスの停止
  • 高速化のためのパフォーマンスチューニング
  • インフラ構成の見直しとコストダウン

作業内容

  • Webサーバーにかなりの余剰リソースが存在したため、ProxyサーバーをWebに統合
  • ステージングサーバーもWEB03に割り当て
  • 蓄積されたデータ量の増加にともないDBのレスポンスも悪化していたためDBチューニングによりレスポンス改善
  • 改善後であっても現行の4倍のアクセスに耐えられるためWebサーバーを1台削除
  • 合計4インスタンスを削除(Proxyサーバー2台、WEB04、ステージングサーバー)

実施後の結果

  • Webサイトの読み込み速度が平均8秒後半だったものが1秒後半までに高速改善
  • 検索結果経由の新規訪問率が5.6%向上
  • サイト訪問当たりのユーザーの回遊率が11%向上

費用対効果

【月額インフラコスト4台分の削減】
1台あたり66,000円のサーバーのため月額264,000円削減(年間316万8千円の削減)
高速化/最適化にかかった費用 1台あたり200,000円×4台=80万円のみ
年間236.8万円のコスト削減に成功

WordPressの改善例

WordPressを使ったサイトが遅かった時にキャッシュプラグインを有効にしてなおかつOSとミドルウェアのチューニングを行って高速化したケースです。

ブログへのアクセス過多が原因で表示に20秒くらいかかっていた。高速化前はレンタルサーバーだったがVPSの16Gプランに変更を行いその後、クラウドサーバーに移行しWEBサーバーをクラスタしている状態で月250~260万PVのアクセスでもどのページの表示が2秒以内に読み込みページ速度が改善され体感速度でも明らかに変わった。

ECサイト(EC-CUBE)の改善例

当時EC-CUBEの古いバージョンを使っていたケースではそのバージョン自体にセキュリティホールがあったため最新のバージョンにアップを行いました。

また商品画像としてアップしているファイルがデジカメで撮影したデータをそのままアップしてあってリサイズが効いていていませんでした。

ImageMagickを導入しリサイズの圧縮比を高く設定してファイル自体を小さくしました。
1つの写真が400Kでも10個並んだら4M。半分以下にしただけでだいぶ効果がありました。

ECサイト(osCommerce)の改善例

osCommerce(オーエスコマース)はEC-CUBEと一緒でオープンソースのショッピングカートです。状況としてはDBにインデックスされてなかったためが商品点数が25000個くらいありリソースが限られていました。

対策はPHPのロードサイズを2~3倍にした。頻繁にアクセス過多になるとPHPで謎のエラーが出ていたため原因を潰すよりをリソースを多くしたほうが早いと判断し、高速化につながった。

表示速度が遅い場合のデメリット

security_691

サイトを閉じる人が増え二度とアクセスしない

ページの表示に6秒かかった場合、離脱率(ページを消す)が25%も上昇し、61%が二度とアクセスしません。

上位表示されてクリックされても表示が遅かった場合、戻って他のサイトに移動してしまって訪問者を取り逃す可能性があります。

得られたはずの売り上げを得られない

自信のある商品・サービスでもページ表示が遅いせいでユーザーを逃している可能性があります。
せっかく商品を買おうと思って購入ページに移動してもサイトの読み込み速度が遅いので他のサイトで購入されてしまう可能性があります。

表示が遅いと似たようなライバルサイトに移動

はじめて訪れたサイトの読み込み速度が遅いとき75%の人が違うサイトへ移動します。
実際の店舗と違ってユーザーは数回クリックすれば他のサイトへ移動することができます。

遅いと感じてしまったら似たようなサービスや商品を扱っている別サイトに逃げてしまうでしょう。

顧客満足度の大きな低下

Webサイトの表示が1秒遅くなるたびに16%顧客満足度が低下します。
遅くなる原因としてはプラグインや記事の写真・画像データが大きく読み込み速度の処理が関係します。

遅くなる考えられる理由

表示速度が遅くなる原因は多種多様ですが主に以下のいずれかもしくは複数による影響が考えられます。


  • サーバーのスペックが遅い
  • サイトのアクセス増加
  • レンタルサーバー(共有サーバー)で他サイトのアクセス増加
  • WordPressなどのCMSを利用しプラグインの影響
  • 画像やプログラムの読み込みファイルが多数

まとめ

レンタルサーバーで高速化出来ることはキャッシュのプラグインを導入したり.htaccessで参照先のパスを圧縮を行ったり、一度訪問したユーザーにローカルに保存して再訪問のページを早く出す程度にとどまります。

VPSやクラウドサーバー(root権限付きサーバー)に移設するとなった場合は、root権限が付いているのでミドルウェアとかOSのチューニングができるため高速化出来る範囲が広がります。

ApacheやLAMP環境で運営していてもボトルネックがどこかを見つけて原因となるミドルウェアを動作に影響が起きなければ交換ができます。Nginxを採用したりmysqlのバージョンをあげたり、DBに頻繁にアクセスする場合はクエリキャッシュを使ったりとかできます。

WEBサイト高速化はどこまで望んでいるかと、何が原因かを把握していて今より早くすることは簡単です。
何が原因で(プログラムが問題か、DBが問題か、ミドルウェアの実行のプロセスが問題など)調べてわかっているけど対処方法がわからないという状態のほうがチューニングはし易いといえます。

その場合はチューニングが明確なので、もちろん全体的にチェックは行いますが具体的に閾値の変更やキャッシュをはるタイミングと開放するタイミングをどのように変更したかなど明確な設定変更が可能となります。

  • このエントリーをはてなブックマークに追加
  • Pocket
  • LINEで送る