ページの読み込みスピード

遅くなる前と後ではどのような違いがありますか？
例えば画像を多用するようになったとか、twitterの何かしらの埋め込みをしたとか。

基本的にwordpressはデータベースにデータを保管していってますから、データが増えれば重くなるのは当然といえば当然です。そのためにデータベースのオプティマイズ(最適化)をするプラグインもあるぐらいですし。
データが増えれば見つけるのが大変になりますよね。生のデータを探すだけではなく、キャッシュにしてもページが増えればその分のキャッシュも増えていくわけですし。

不要なプラグインの残骸とか、テーマ、その他諸々要因はあります。

ブログカードはその都度データを読みに行っていたり(外部のものは一時的にキャッシュしてますが)するので重くなります。

一番軽い状態と言うのは、テキストです。つまりPHPで処理をせずとも表示されるようなテキストが一番軽く、データを取得して整形と言う処理が入ることで重くなって行きます。自分のサーバーなら比較的速いですが、それでもそのデータがHDDにあると考えると、アクションを起こしてからデータをサーチしてそのデータを処理すると言う一連の流れの中で、HDDは人の想像よりもずっと速く動作してますが、遅い部類のストレージです。

ファミコンとプレイステーションを比べるととてもわかりやすいです。ファミコンはROMでつまりメモリです。PSはCDでデータを保存しています。電源スイッチを入れるとすぐに起動するファミコンと違い、PSはしばらくローディング画面があってゲームが始まります。
なぜ遅いかは、回転しているメディアからデータを拾っているからです。性能は段違いなのに、拾ってくるデータが大きくなるのと同時に回転してるメディアからデータを拾ってるので遅いんです。

できるだけHDDにアクセスせずにデータ自体も軽くなればおのずと速度は上がります。ここで何がネックになるかはデータをどこからどのようにして読み込んでいるかです。

つまり、ページがどのように作られているかがポイントの一つで、HDDのへのアクセスを減らすというのはもっと細かく言えば、httpリクエストを減らすと言うことでもあります。

画像の読み込み点数を減らす、外部からのデータの取得をできるだけないようにする、するのであればキャッシュできないかを考える、そして無駄なリソースは読み込まないと言うのが一番大きいかもしれません。

無駄なリソースの代表格はシェアボタン等SNSへのリンクやデータ取得、そして広告です。
この2つを外すだけでだいぶ軽くすることは可能です。遅くなるのの代償に収益を得るのであれば、なるべく速いサーバーを使うしかありません。

デベロッパーツール等でネットワークやパフォーマンスを調べることで何がネックかは大まかにわかります。他にもスピードテスト等のサイトを利用してもよいかと思います。具体的に何がネックなのかがわかればそれに対応するためにどうすればよいかは何かしら知恵を出せるかもしれません。

いえ、特に何もしていません。

PageSpeed Insightsでこちらのsimplicity様のＵＲＬをチェックさせてもらったのですが、やはり明らかに遅くなっているように思われます。

と書きましたように、こちらの読み込みスピードも遅かったので、投稿させていただきました。

サーバーはＷＰＸでwpXカスタマーサポートに最初に問い合わせしたのですが、

▼取得に時間を要していたデータのURL(ごく一部)
http://cdn.api.b.hatena.ne.jp/entry/button/?url=http%3A%2F%2Fstjohngogarty.com%2F&layout=vertical-balloon
http://connect.facebook.net/ja_JP/sdk.js
https://d7x5nblzs94me.cloudfront.net/v1/j/shared.js?v=2

上記のようなデータ１つ１つの呼び出しに時間が掛かっており、
外部から呼び出しているデータがやや多数なために、
特にInternet Explorerなどのブラウザでは表示に時間を要しておりました。

という返答が返ってきたところです。

Simplicity公式は元から遅いですよ（笑）
ほぼ完全にデフォルトですし、外部のサーバーから読み込みしている部分もありますし、できるだけカスタマイズせずにできることを再現するためか無駄に表示部分が多いでしょう？
例えばptengineとgoogle analytics併用したり、重いものも構わず掲載していて、かつほぼデフォルト表示しているんですから重いです。

またcssやjsの圧縮もされていません。レンダリングブロックに対しても何かしら対策をしているわけではないです。これらをすると、一般的なユーザーが手を入れる時に色々と問題が出たりするのを嫌っているわけです。いや真意はわいひらさんしかわかりませんけどね（笑）

素の状態で問題なく提供することで、後は利用する人がそれぞれにカスタマイズしてもらえるようにという配慮でもあると思います。そのため、本来なら1つでよいはずのcssをわざわざmobile.cssやstyle.cssだけでなく、responsive.cssとか、無駄に分類されているでしょう？
これは速度やら快適性よりもユーザビリティを上げるための処置ですよ。facebook等を利用してない人にとってその分のスクリプトやcssは不要なはずですが、誰がどう利用するかわからないと言うのも含めてテーマに同梱してあるわけです。

前レスでhttpリクエストを減らすべきだと書きました。これはcssをできるだけ1本化していくつも読み込むリクエストを投げないと言うことです。ページを読み込むごとに何かしら処理をさせず、キャッシュがあるならキャッシュを利用してと言う方が速いに決まってますよね。

はてなボタンは、SNSのボタンを高速タイプにした方がよいです。カウント値だけ取得して、テーマ側でボタンを作ってるので、負荷はかかりますが速くはなります。高速タイプを使わなくても高速タイプのcssは読み込んでいるんです。だったら無駄にCDNからcssやスクリプト読み込むより、カウント値のやり取りだけで表示する高速タイプのほうが速いですよね。
ただ、自サーバーが遅いのであればCDNは有効です。

facebookは基本海外のサーバーですからデータを取得するのは遅いです。twitterもしかり。これが常にトラッキングしているので重くなること必須です。応答自体は速いかもしれませんがデータの伝達速度が遅い感じでしょうか。なので、GoogleにしてもtwitterにしてもCDNでデータをキャッシュしたり、その分野の天才たちが世界中のどこで利用してもほぼ時差がないような仕組みを作っているわけですが、いかんせん利用者が多いのでどうしても遅くなります。

しかも日本人は遅いサービスに群がりがちです。なので輪をかけて遅くなってしまいます。
遅いなら使わなきゃいいじゃんと言う意見もありますが、これはあながち間違いではないと思います。

twitterがカウント提示をやめるぜって去年の11月ぐらいに言いましたよね？サードパーティ製と言うのもあったとは思いますが、カウント提示してどうする？と言う感じでした。ちょっとでも速くしたいわけです。カウントに意味があれば提供もするでしょう。が、twitterは止めました。それはそこにリソースを割くほど意味がないと言うことです。しかし人はカウントを取得したがりますよね。
で、count.jsonが廃止されたらcount.jsoonをまた作り出したりしているわけです。そこまでしてカウントを表示したいか？と言うところですよね。シェアボタンはシェアできたら良いわけで、カウントはその指標にはなりますが、一番影響があるのは膨大なフォロワーがいる人にシェアしてもらうことです。
膨大なフォロワーを保持している人がそのカウントの数値からわかるか？と言う事ですよ。

速くしたいならカウントも廃止するべきです。そしたらリンクだけで済みますから、表示はかなり速くなると思います。

最後のは何か知りませんが、これら全部読み込み先のサーバーの応答が遅いから表示に時間がかかっているだけで、遅延処理等をしていないから他のものがレンダリング待ちになったりして時間がかかっているだけだろうと思います。
これはサーバーに負荷をかけていると言うわけではなく待たせている時間が多いんじゃなかろうかと。それを負荷と言うなら負荷ですけどね。

IEは基本拡張機能があまり無い分速いはずですが、基本MS（笑）なので、IE情報は何の参考にもなりません。MSは独自機能とOS依存部分があったりしたり、標準的なwebの仕様から外れている部分が多々あります。IEをこんなに使ってるのなんか日本ぐらいですよ。

参考: ブラウザシェア | W3Counter’s と、その他諸々

このIE利用者の内、6割ぐらいが日本と韓国と言われてます。これはネトゲするのにIEと言う場合が多いとか未だにActiveXとかを利用するサービスがあったりするのが理由じゃなかろうかと思ったり。特に企業とかはセキュリティ云々と言いながら、新しい環境に移行する費用を出すのが嫌で未だにIE6とか、マジかよって所もあります。

で、質問冒頭にスマホに限ってとありますが、PCの表示と比較的非力なスマホを同じweb環境で読み込んだらそりゃスマホの方が重いですよね？
そのためにGoogleがAMPがどうだとか、jQuery使わずにzepto.js使えだとか色々モバイル用に別の環境を作ろうとしているわけです。

スマホの時に、フッターを非表示にしたり、サイドバー部分を表示しないようにしたり、スマホ用の環境をなんとか実現しようとする中、やはりスマホでもそれなりのデザインをと考えてしまいがちです。

スマホなんぞはテキスト主体で良いわけですが、画像を載せたいとかfacebookと連携したいとか使いたいのはわかりますが、それをするためにPCと同じ環境でしていてはダメなんです。グラフィカルなサービスはネイティブに対応できるアプリでやるべきです。
またスマホでIEは使えませんから、wpXカスタマーサポートの返答もアテにはなりません。

逆にスマホに最適化すればPCはもちろん軽くなりますよね。なので世間ではモバイルファーストと言うわけです。

了解いたしました。ありがとうございました。

あと、このテーマを利用している人は初心者が多いと思うので、有料サポートも
作っていただければ幸いです。

色々専門的なことを書かれてもわからないので、興味があればよろしくお願いします。

wordpressで読み込まれているjavascriptにdeferもしくはasyncをつける | blazechariot -Xdomain-

こんな記事を書きました。
レンダリングブロック等で、読み込みに時間がかかっていると言うような場合は一度お試しください。

ちなみに上記async/deferをつけたものを、firefoxとchrome(chromium)で試してみました。
firefoxはキャッシュなしです。

firefox トラッキング保護有効 + ublock有効 で 7〜8秒
firefox トラッキング保護有効 + ublock無効 で 8秒後半後
※ トラッキング機能無効は、ublockが効いているとトラッキングが検出されません
firefox トラッキング保護無効 + ublock無効 で 18〜22秒前後

上記async/defer無効時
firefox トラッキング保護有効 + ublock有効 で 7前後秒
firefox トラッキング保護有効 + ublock無効 で 6秒後半〜9秒
firefox トラッキング保護無効 + ublock無効 で 18〜22秒前後

上記async/defer無効時
Chrome ublock無効 で、6秒前後
Chrome ublock有効 で、4〜5秒前後
Chrome シークレットウィンドウ + ublock有効 で、3秒後半前後
Chrome シークレットウィンドウ + ublock無効 で、4〜5秒後半前後

上記async/defer有効時
Chrome ublock無効 で、6秒前後
Chrome ublock有効 で、4秒中盤前後
Chrome シークレットウィンドウ + ublock有効 で、3秒後半前後
Chrome シークレットウィンドウ + ublock無効 で、4〜5秒後半前後

ここからもわかりますが、ページの表示自体は速くなっているかと思いますが、全体の読み込みは後から読み込んでいたりする要素があるのであんまり差はないかと思います。
PageSpeed Insightsは、このページの表示自体を速くしましょうと言うことで、訪問者を待たせずすぐ読みめるようにするためのもので、結局後回しになっている要素が読み込まれる分全体的な重さは変わりません。
chromeがどんな状況でも概ね速いと言うのはわかりましたが（笑）

ublock等で広告を排除するだけでfirefoxでは10秒近く速くなると言うのは凄いですね。普段からトラッキング防止ONなのであんまり気にしたことはなかったですけれども。

うちの環境ですが、はてな、pocket、feedlyが重かったです。次いでfacebookでしょうか。これらを読み込まなければ、
「firefox トラッキング保護有効 + ublock無効 で 8秒後半後」→これが5秒前後になる感じです。

やはりと言うか当たり前ですが、外部読み込みを制限するほうがページ自体の読み込みは軽くなるのは間違いなさそうです。PageSpeed Insightsの数値はあまりアテになりませんが、レンダリングブロック、あるいはcssをなんとかしろと言うような修正点を知ると言うことでは有用です。
うちのサイトはhtaccessに制限があるのでgzip等が使えないわけですが、これらが使えればSimplicityでも80点〜90点あたりは狙えるのではなかろうかと思ったりしてます。

Simplicityでも80点〜90点と言うのは語弊があるとアレなので書いておきますが、cssをかなりシェイプアップして1本化、不要なスクリプトの読み込み禁止、ウィジェットもなるべく使わず(wp popular linksとか)、親テーマjavascriptを自分のサイトに最適化、画像は別サイトから遅延読み込みあるいは使わないデザインで、webfontは使わず、SNSのボタン等のfontAwesomeは禁止、cssスプライトに変更 + fontAwesomeはCDNで読み込み、icomoonも使わず…etc.

とパッと思いつくだけで、これぐらいはしないといけないかもと思ったりします。

twitterとかfacebookはページにつき1つぐらい何かしら読むぐらいの量で、シェアボタンはリンクのみ(カウント取得せず)、広告もできるだけ使わない方向で行く必要もあるだろうと思われます。

これらをして、より魅力的なサイトになるのであればそうするべきです。この手間と今後のメンテナンスやらを考えると、ページの構成のみを再考するほうが何かと楽かなぁと思ったりします。

できるのであればですが、functions.phpで読み込んでいるような機能はプラグイン化して、サイトから選択した内容だけが含まれるプラグインのダウンロードができると一番理想的でかつシンプルで軽く使えます。これは色んな意味で1から作り直したりする必要があるので今の所は夢物語です。
不要な機能は利用する人が最初からインストールしなければよいので軽く使えますが、サポートが難しくなるのも諸刃の剣。

もうひとつ提案できるとすれば、X-SERVER系は全部かはわかりませんけれども、うちのX-domainなら、wordpressサーバーの他にPHPサーバーとhtmlサーバーが使えます。
定型文と言うか、特別wordpressを使わなくても良いようなページは、これらに移植して、ブログカードで読み込めば(リンクすれば)同じサーバー内(だろうと思われる所)から読み込むわけですので、比較的軽くイケるのではなかろうかと思ったりもします。

ここらも含めてページの構成を再度考えられるとよりよいサイトができるのではなかろうかと思います。全部をwordpressで賄うから重いと言うことですから、そこらをどうするかですよね。

ちなみにどうですか？
表示速度は速くなりましたかね？
pageSpeed Insightsも後一歩で80点いきますな。何のgifかわかりませんが、これは有効期限を入れたら行けそうなのでhtaccessで設定ですかね。

問題としてはcssで色々と言われているところぐらいでしょうか。ここらは、まぁ普段利用では問題ないと思いますが、気になる場合は何かしら方法を考えねばいけませんね。

> $async_deferのハンドル部分は以下のように
> 変更しないと適用されないようです。

ここは、デフォルトでjquery-migrateを読み込んで古いIEとかにも対応させようとしている部分もあるからかと思います。
ウチの場合はjQueryをキャッシュさせているので、予め、
wp_deregister_script( 'jquery' );
でjQueryを解除した後、GoogleCDNのjQueryを読み込ませていて、その時に新たにjqueryのハンドルがつけているのでjquery-migrateを読み込まず、jQuery単体で動作しているってのがあってjQueryだけでイケるんですが、async deferの指定だと、jQueryがやはり読み込み失敗になってしまって、他のも巻き添えになることがあるんですよね。

なので、記事にはasync deferで書きましたが、個人的にはdefer推奨します。別の言い方で言えば、閉じbody前にjQueryを書くと言う感じです。
後は、何度か読み込み時にデベロッパーツールを開いておいてエラーが出たらdeferの方へ移動していく感じかと思います。
lity-jsはasyncでイケるかなぁと思ったんですが、たまに読み込み失敗しますね。こんな感じに色々調整する必要はありそうです。