WebHostingPadで快適なサイトを作る

と、いうことで前回はWebHostingPadの酷い？状況を記事にしたので契約しようかと思っていた人もすっかり興味を無くしていただけたことと思います。

WebHostingPadの何が問題なのか整理します。

遅い
すぐにリソース不足になる
制限がある
サーバが停まる

1.の「遅い」ですが、何が遅いかというと「処理速度」です。「通信速度」はそれほど酷くありません。
(ただし、管理者用のFTPとかファイル転送はびっくりするほど遅いです)
どうすれば解決できるかというと「処理させない」これに限ります。例えばWordPressなどはアクセスがあると動的にページを作る処理を行って作ったページを表示させています。WebHostingPadではこのページ作成処理が「遅い」のでページ表示に時間がかかります。閲覧する側にはページ作成が遅いのか通信速度が遅いのかは良く解りません。とにかく「遅い」と思わせる原因になっています。かといって今どきHTMLファイル作ってサイトを作るということもやりなくないところですし、CMSには有用な機能が多いので使わないというのはキツいです。ただ、常に動的にページを作らないといけないかというと実はそうでもないというのが多くのサイトでは実情ではないかと思われます。例えばブログで○月○日の日記というページを表示する場合、そのページは表示する度に毎回劇的に変わる訳ではない筈です。このようなページは作り置きしておきます。それがファイルキャッシュと呼ばれるものです。
客から注文が入ってから魚を焼いて「定食」を作るのではなく、焼き魚を作り置きしておいて注文されたら皿でヒョイと出せば速くなる訳です。

2.は1と同じです。WebHostingPadではページ作成「処理」でリソース不足になるので処理させなければ良いのです。

3.制限については、WebHostingPadのAbuse Termsに記載されています。
要点としては

WebHostingPadのサーバやネットワークに悪影響を及ぼすと考えられるスクリプトNG
転送量の制限は無し、ただし与えらえれている性能が足りないなら連絡必要。
ディスク容量は制限無しだが、バックアップ目的の利用はNG。
ファイル数は15万まで。それ以上はVPSサービスに移行するか5万ファイル毎に月$10必要。
割物禁止
ディスク容量の初期割り当て値(約10GB)の10%を超える(要するに1GB以上)動画ファイル等はNG
DBの容量がディスク容量の初期割り当て値(約10GB)の10%を超える(要するに1GB以上)のはNG
CPUとメモリを10分以上10%の使用量(与えられているリソース中)を超えて使い続けるのはNG
電子メールは1時間300通、1日3000通を超えて送受信NG
上の理由を3回以上行ったり60日中断した場合はアカウント削除

i.はサーバに負荷かけるようなスクリプトだとNGだと思われます。NGと判断するのはWebHostingPadなので疑われないようにするしかありません。バックグラウンドで実行するようなものは止めておいた方が無難です。
iiは制限無しの筈が転送量の初期値は100GBです。日記レベルのブログ(例えばここ)なら全然余裕ですが、アクセスの多い情報系サイトは厳しいでしょう。相談しないと増えないあたりも実際には制限があると言えます。cPanelのメイン画面で確認できます。
iv.のファイル数制限は日記サイトなら大丈夫ですが、大きめの情報系サイトなどをキャッシュファイル使ってやるなら場合によっては苦しくなる局面があるかも。しかもファイル数の確認方法が見当たりません。
viii.のCPU/メモリ使用率制限は厳しいのでサイト構築直後からしっかり対策しておかないと何時アカウント停止になるか解りません。cPanelのResource Usageを見ながらハラハラするしかありません。

結局のところ3.も1. 2.と同じ対策になります。処理しなければ負荷がかかりません。

4.のサーバが停まるについてはWebHostingPadが停まっても大丈夫な体制を作るのが良いかと思われます。

キャッシュ化

CMSに限らず最近のウェブアプリケーションはページをキャッシュ化して高速且つ低負荷を実現する仕組みが用意されていることが多いです。特にMODxなどキャッシュ機能が標準で動くCMSもあり、これらはWordPressに比べると最初からとても軽く感じます。WordPressにもファイルキャッシュ化用ののプラグインが沢山用意されていて、WordPressなどを使っている人は既に知っている人が多いかと思いますが人気があるのがQuick Cache、W3 Total Cache、WP Super Cacheなどです。
導入方法はWordPressなら普通に管理画面のプラグインのメニューから「新規追加」を選び入れたいプラグインの名前を検索して「今すぐインストール」でインストールして有効化すれば良いです。
今回は以前から使い慣れているWP Super Cacheを使うことにします。
ちなみに利用したいのはファイルキャッシュであって、他の方式のキャッシュはメモリを喰うことがあるのでWebHostingPadでは採用しない方が良いでしょう。

WP Super CacheをインストールしたらWordPressの管理画面の「設定」から「WP Super Cache」を選びます。
設定画面の上部にある「詳細」タブを開いて幾つかあるチェック項目で「(推奨)」というのが付いている項目にチェックを付けます。推奨になっていない項目ですが「Mobile device support」にもチェックを付けておきます。

設定ページの真ん中辺りまで進むと水色の「ステータスを更新」ボタンがあるので押して保存します。
その直下に「Mod_Rewriteルールの参照する」を押して現在のWordPressのフォルダ(ドキュメントルート)直下の.htaccessと/wp-contents/cache/.htaccessの両方の内容を(1画面に)表示させて念の為にエディタなどにコピっておきます。
その下の「Mod_Rewriteルールを更新」ボタンを押すと.htaccessにWP Super Cache用の設定が自動的に書き込まれます。
その下の設定は好みで触るか触らないかで構わないです。

設定画面の上部にある「簡易」タブを開いて最初の「キャッシング利用 (推奨)」に○をつけて水色の「ステータスを更新」ボタンを押します。
その下の「キャッシュをテスト」ボタンを押し

下のテストボタンをクリックするとキャッシュされたページをテストできます。
キャッシュを準備するために http://example.com/ を取得: OK
http://example.com/ の最初のコピーを取得中: OK (1.html)
http://example.com/ の二つめのコピーを取得中: OK (2.html)
ページ 1: 2014-mo-dd hh:mi:ss
ページ 2: 2014-mo-dd hh:mi:ss
両方のページのタイムスタンプがマッチしました !

という表示になることと「二つめのコピーを取得中」の右側の水色になっている「2.html」を表示させ、そのURLがhttp://example.com/wp-content/cache/2.html (example.comの部分はあなたのサイトのホスト名)であればWP Super Cacheは正しく機能しています。そうならない場合は2つの内どちらかの.htaccessに問題があるかと思われます。Error500などでサイトが表示できなくなった場合も.htaccessに問題があると考えられるのでWebHostingPadのcPanelからファイルマネージャを開きサイトのホスト名のプルダウンを選択して直下の.htaccessと/wp-contents/cache/.htaccessをそれぞれ右クリックして「Edit」を押し、メモっておいた.htaccessに戻すか比較して修正します。

WP Super Cacheを設定する前と有効化後(ブラウザでサイトにアクセスしてキャッシュが作られた後に)にページ表示速度を比較してみます。ただし、サイトやページによって重さが違うので参考程度にして下さい。

表示速度はhttp://webwait.com/で計測しています。このサイトでは自動的に5回読み込んで計測してくれます。

キャッシュ無し時: 4秒前半 (平均)
キャッシュ有効時: 2秒前半 (平均)

自宅のサーバで動いているサイトでキャッシュ有効だと0.15秒くらいなので、もっと劇的に変わるかと思ったら半分にさえ成りませんでした。ただし、自宅のそのサイトは広告無しで今回WebHostingPadに設置したサイトは広告有りなので単純には比較できません。(広告の表示は結構時間かかります。)
とはいえ、他の部分も攻めないといけないようです。

今度はページ内のそれぞれのファイルの表示とページ表示における問題点と改善方法を教えてくれるGTmetrixで表示してみます。

調整を行っていないサイトの場合はたいていの場合、サマリが「C」程度の評価になります。
要改善箇所として指摘される項目もこの画面のように「gzip圧縮を有効にしろ」だの「ブラウザのキャッシュ時間の指定をしろ」だの「CSSの無駄をなくせ」だの「Vary Accept-Encodingヘッダを設定しろ」だのという定番のものとなります。
と、いうことで対応も定番です。

Enable gzip compressionの対応

指摘されている項目をクリックするとページの何がその項目で引っかかったか表示されます。この指摘が出るのは多くが.cssや.jsのファイルです。要するにCSSとJavaScriptです。これらをgzip圧縮するように指定します。
サイトのドキュメントルートの.htaccessに次を追記。

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/css application/x-javascript text/x-component text/html text/richtext image/svg+xml text/plain text/xsd text/xsl text/xml image/x-icon application/javascript
  <IfModule mod_setenvif.c>
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4\.0[678] no-gzip
    BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
  </IfModule>
  <IfModule mod_headers.c>
    <FilesMatch ".(js|css|xml|gz|html)$">
      Header append Vary: Accept-Encoding
    </FilesMatch>
  </IfModule>
</IfModule>

Specify a Vary: Accept-Encoding headerの対応

上に一緒に入っています。(8〜12行目)

Leverage browser cachingの対応

指摘されている項目をクリックするとページの何がその項目で引っかかったか表示されます。この指摘が出るのは多くが画像ファイルやCSS,JavaScriptファイルです。それらのファイルの有効期限をブラウザに通知してできるだけブラウザのキャッシュを表示するよう設定します。
サイトのドキュメントルートの.htaccessに次を追記。

<ifModule mod_headers.c>
  <Files ~ ".(gif|jpe?g|png|ico|js|css|gz|svg|swf)$">
　  Header set Cache-Control "max-age=2592000"
　</Files>
  Header set Connection keep-alive
  Header unset ETag
</ifModule>

ちなみに2592000の単位は秒で30日を意味します。
ついでkeep-aliveの有効化(5行目)とETagの無効化(6行目)もしています。

Minify CSSの対策

CSSのコメントや行頭の字下げを無くして無駄を省けというわけです。
指摘されている項目をクリックするとどのCSSファイルが引っかかったか表示されます。さらに「See optimized version」の部分をクリックすると無駄を省いたCSSを表示してくれるという親切ぶり。保存して入れ替えると対応完了ですが、これを実行すると結構手間かかるし、後でCSSを変更するのも管理も大変。cssはgzip圧縮もしているのでこれは勘弁して欲しいところ。実際がとはこれはいつも行いません。
WordPressの場合はHead Cleanerプラグインを使うと対応できたりします。

対応結果

GTmetrixで再表示してみます。

サマリーのPage Speed Gradeが「A」YSlow Gradeが「B」ということで、修正前のC,Cと比べるとかなり改善したように見えます。
Page Speed Gradeで評価評価の高くなかったLeverage bowswer cacheingとRemove query string from satic resoucesの項目については上で対策済みでWebHostingPadに置いたサイトについては問題が無いのですが、ページに読み込んでいる広告が外部サイトのものでその画像ファイルが適切にGTmetrixの望む設定になってないためにこの評価になっています。外部サイトのものなのでどうしようもありません。
Remove query string from satic resoucesについては例えば/PATH/jquery.clicktracker.js?ver=0.6のように末尾にバージョンが付いたものが指摘を受けています。これも特殊な対応が要るので無視します。

表示速度はhttp://webwait.com/で再び5回計測した平均です。
キャッシュあり: 1.5秒。
1.5秒ならストレスを感じない範囲といったところでしょうか。
ちなみにブラウザで見える範囲(広告を除く)の表示が3秒を超えるようなサイトは人に来て貰うのが難しくなるし、グーグルの検索結果で上位表示も無理と思った方が良いです。(最近はページの表示速度も評価対象らしいです。)

ちなみに外部サイトからの広告を表示しないページはこのような評価となります。サマリーはA,Aになっています。
表示速度はhttp://webwait.com/で再び5回計測した平均です。
キャッシュあり: 0.4秒。
意外と速いです。つまり約1秒は広告表示だったわけです。

こちらはGTmetrixの診断結果で「Timeline」のタブを見たものです。画像を少し加工をしています。スクロールしなければ見えない部分を1つの画像にしているのと薄い水色と薄いピンクで着色しています。あと、モザイクも。診断内容自体は加工していません。
薄い水色部分がWebHostingPadに置いたサイトファイルを表示している部分で薄いピンクの部分が広告サイトの広告関係ファイルを表示している部分となります。
Timelineを見ても広告が表示時間の約半分を占めています。
ただし、実際はブラウザでスクロールしなくても見える範囲内がサクッと描かれれば、また広告以外の部分が早い段階で表示されれば閲覧者のストレスは溜まりません。ときどき広告が表示され終わるまでサイトのコンテンツが表示されない作りになっているサイトを見ますが、通常時でもページの表示に時間がかかりますし、広告プロバイダ側で遅延が発生すると引きずられて自分のサイトも表示に凄く時間がかかるようになるのでそのような作りにはしないようにした方が良いです。

実際のところ、サイトの表示高速化の大部分はキャッシュ化によるものですが、他も細かく潰していけば塵も積もればで表示速度を改善させられます。また、キャッシュ化のおかげでCPUの負荷もかなり抑えられるようになりました。

キャッシュ化されていないページは処理されるためにCPUの使用率のMAX値はそれなりにあるものの、緑の平均値のほうが0付近に張り付くようになりました。これなら直ぐに追い出されることもないでしょう。
これならWebHostingPadでも十分にやっていける気がします。

~~次はWebHostingPadのサーバ停止対応です。~~

ごめんなさい。サーバ停止対応の記事はWebHostingPad以外にサーバがある前提で、ある意味卑怯技なのでボツにしました。(CDN ﾎﾞｿｯ)