タグ別アーカイブ: site optimization

Future of Responsive Images

レスポンシブデザインの進化はWebの常識を変えるか?

ある記事 によれば、レスポンシブ Web デザインを採用するサイトの 72% が、デスクトップとモバイルに同じリソースが使われているそうです。またそれらリソースの 60% 以上が画像 という統計や、モバイル用に画像を最適化すれば、データ量を 72.2% 削減できる という調査結果もあります。

ということで、レスポンシブ画像のことを調べていていましたが、その技術進化というか、紆余曲折も含めて色々とある様です。

最新技術を素早く取り入れることはもちろん大事ですが、特に過渡期においては、変化に強いサイトを作るためにも技術の先行きを見極めることが重要です。そこでタイトルのような視点で、これまでの経緯をつらつらと辿ってみました。

自分としてのテーマは、「じゃあ、今、どうするか?」だったのですが…。読んで下さる方の何かに役立つかどうかは甚だ心もとない記事です。

ちなみに今回記事で取り上げた話題については、レスポンシブ画像のデモ に、もう少し掘り下げて展示しています。そちらもぜひ覗いてみて下さい!

続きを読む

Sample Site

GradeAの先行くWordPress高速化 – 必ず結果の出る実践的HTTPリクエスト削減法

WordPress は、プラグインで手軽に機能が拡張できる反面、あちこちに css や js が散乱し、放っておくとベスト・プラクティスからは程遠い状態になりがちです。

もちろんこういった問題の解決を図るプラグインも多数リリースされていますが、ページ単位の処理なので、サイト全体の構成を通して最適にはなりません。

そこで第1部「サイト高速化の「戦略」と「戦術」- GradeAのその先へ」、第2部「サイトに適したリソース配置とasync/defer完全マスター – レンダリング優先のグッド・プラクティス」では、数あるベスト・プラクティスの全体を俯瞰し、個々の Tips やテクニックからは見え難い、最適化の考え方や道筋を提案しました。

その総仕上げとして今回は、WordPress サイトを例題に、必ず結果の出る HTTP リクエストの削減方法を提案したいと思います。

続きを読む

ContentLoded.com

サイトに適したリソース配置とasync/defer完全マスター – レンダリング優先のグッド・プラクティス

タイトル、少し変えました 😉 。

第1部「サイト高速化の「戦略」と「戦術」- GradeAのその先へ」では、YSlow や PageSpeed がアドバイスする Tips のうち、HTTP リクエストの削減を優先すべしという「戦略」の話をしました。

また css や js を束ねて結合し、HTTP リクエストを削減する時の「戦術」の話もしました。

今回は、「サイトの特性に適したリソースの配置を行う」ために、「束ねたリソースをドキュメント中にどう配置するのが適切か」を見い出したいと思います。またそのポイントとなるブラウザの基本的な挙動についても言及します。

ブラウザごとの挙動が確かめられる、実験サイト contentloaded.com を立ち上げたので、以下、同サイトから幾つかの例を引きながら話を進めたいと思います。

続きを読む

After Grade A

サイト高速化の「戦略」と「戦術」- GradeAのその先へ

サイト高速化をネタにした記事は星の数ほどありますし、YSlowPageSpeed、あるいは両方同時にチェックできる GTmetrix のおかげで、アドバイスに従って問題点を一つ一つ潰し込んでいけば、着実にスコアを「Grade A」に近づけられるようになりました。

またベスト・プラクティスなんて知らなくても、「CloudFlare 導入、一発 OK!」なんていうお手軽なサービスもあります。

一方、これら個々の Tips、テクニックを断片的に積み上げていくアプローチやブラックボックス方式では、サイト全体を通して「本当に最適なの?」という疑問も生じます。

別な言い方をすれば、「Grade A は取ったけど… その先は?」に対する処方箋が必要なんじゃないかと思っています。

そこで今回は、「スコア」だけでは見えてこない、サイト高速化の「戦略」と「戦術」の話にチャレンジしてみたいと思います。これはフロントエンドという下流のテクニックや Tips の話ではなく、サイトの意図や狙いという上流の要求をフロントエンドという下流に落とし込むための「分析」と「設計」の話です。

ぶっちゃけた話、ろくに設計もしていない(あるいは期せずしてそうなってしまった)乱雑な HTML を、小手先の Tips でいくら弄っても限界があるのは自明の理でしょう。

第1部では、いわゆるベスト・プラクティスの全体を俯瞰しサイト高速化の「戦略」を検討します。第2部では、サイトの要求に適した攻め方、つまり「戦術」を練ります。そして第3部では、戦術に基づいた「実践」について書いてみたいと思います。

続きを読む

ソーシャルメディアの読み込みはDNSプリフェッチのまとめ設定がお得

zenback の読み込みコードが非同期化され、かつ 平均20%+の速度アップが図られた そうで、ユーザーとしては嬉しい限りです。

zenback に限らずソーシャルメディアの導入は、必然的に外部サービスを多用することになります。どのサービスも、スクリプトや画像、トラッキング用コードなどのリソースを、その特性に合わせて 2〜4 程度のホスト/ドメインに分散させているのが普通です。

こういった分散化は並列に読み込みめるリソース数を増やし、クッキーのあり/なしを区別できるので高速化に寄与します。が、利用するサービス数が多くなると、いわゆる「DNS ルックアップ」にかかる時間が無視できなくなり、さすがにデメリットの方が目立ってきます。

例えば本サイトの場合、最終的に25以上の異なるホスト/ドメインから 有象無象 のリソースを読み込んでいるのですが、「DNS ルックアップ」の合計だけで1秒を超えることなどザラにあることが分かりました。

今まで「大して効果ないんじゃない?」と「DNS プリフェッチ」の導入は見送っていましたが、この1秒を消し去ってくれれば幸せになれるかも…と思い直し、導入することにしました。

ということで、今回は twitter や facebook などのソーシャルボタンに DNS プリフェッチを導入した時の効果を報告したいと思います。

続きを読む

サイト速度とonload再考

単にウケ狙いなら「革新的!GAのページ平均読み込み時間を劇的に速くする方法」とか「もう3rdパーティーに邪魔させない、超高速スクリプト読み込み術」(笑)とかの煽りタイトルを付けるところですが、今回はもっと本質的なことを論じてみたいと思います。

プログレッシブレンダリングでUXを向上させるJS非同期読み込みのベストプラクティス」では、スクリプトの読み込みと実行を window.onload 対象から切り離し、見た目のページ速度を速くする方法について書きました。この方法は既存のスクリプトを書き換える必要があるため、Stoyan Stefanov によって 実験的に実装された Facebook SDK か、自前のスクリプトにしか適用できませんでした。

しかし今回、Hatena や Twitter、Pocket、Disqus など、他の 3rd パーティ製スクリプトにも適用できる方法 − “進化版 frame-in-frame 法” を見い出しましたので、その方法を共有し、それがもたらす結果について掘り下げてみたいと思います。

まずは、デモからご覧ください 😀 。

続きを読む

プログレッシブレンダリングでUXを向上させるJS非同期読み込みのベストプラクティス

iOS Safari

本ブログでは、サイトの高速化に直結する「JavaScript 非同期読み込み」の話題を多数取り上げてきました。タイトルに釣られてこの記事を見てくれている方なら Google Analytics の非同期コードスニペット はご存知でしょうし、規模の大きいサイトやアプリ用に RequireJS などのフレームワークを使っている方もいるでしょう。

GA も RequireJS も、動的に生成したスクリプト要素を DOM に埋め込む「DOM 挿入法」が用いられています。さらに遡れば、Steve Souders が 2009年4月の記事 ノン・ブロッキングなスクリプト読み込み で、6つの手法に分類しています。

果たしてこれらの方法は、サイトの高速化にとってベストなのでしょうか?

答えは2012年12月の海外記事にありました。そこで本エントリーでは、日本ではほとんど取り上げられていない Frame in Frame という ノン・オンロード・ブロッキングなスクリプト読み込み を紹介し、タイトルの様な視点で、その活用方法を考えてみたいと思います。

続きを読む

フツーここまでやらない、キャッシュヒット率100%で運用するWordPress高速化

プリロード導入前後の平均表示時間の推移

キャッシュ系プラグインを入れて速くなった気がしていても、Google Analytics の「サイト速度」が思ったほど速くなってない、なんて言う経験はないですか?

今年の4月に発覚した WP Super CacheW3 Total Cache の、心底ヤバイ 脆弱性騒動 も乗り切り、懲りもせずタイトルの様なことを試しています 😉 。

特に共有サーバーで運営しているよいこの皆さんは、絶対にマネしちゃイケナイ、本サイトのヒミツを暴露しちゃいますネ 😉 。

続きを読む

たった1行でケータイやスマホ用ページを高速化するQuick CacheのTips

WordPress の WPtouchKtai Style とキャッシュ系プラグインを 併用 する場合には、キャッシュさせないように設定するのが一般的でした。なぜなら、同じ URL のページを、デスクトップ用とモバイル用のキャッシュに分ける事が難しく、両者が混在しちゃうという問題が発生するからです。当然、ケータイやスマートフォンは、キャッシュの恩恵が受けらないですよネ。

ところが Quick Cache なら、オプションでたった1行のコードを設定すれば、それぞれのページを別々にキャッシュできちゃうんです。

ということで、前回記事 では wp-config.php にコードを追記しましたが、今回はもっとスマートに、Quick Cache 側に設定する Tips として紹介したいと思います。
続きを読む

WordPressプラグインの重い処理をバックグランドで非同期に実行する方法

Lacoocan が重たい腰を上げ、今年3月末から MySQL5 が利用可能 になったのを機に、WordPress を 3.4.2 に上げると共に、プラグインを1から見直しています。

すぐに キャッシュ系プラグイン に手を出すのではなく、なるべく素の特性を観ながら、選ぶ楽しさを味わうのもイイかなと。

そんな中、Google Analytics (以下 GA) の集計結果を読み込み人気記事として表示する Google Analytics Popular Posts (以下 GAPP) というプラグインを使いたいと思ったのですが、そのキャッシュ設定をオンにしても、GA との通信で更新に数秒かかってしまうという問題に直面しました。

つまり、たまたま更新のタイミングに当たった運の悪い人にとっては、重たいブログとなってしまうのです。

そこで今回は、そういったプラグインに起因する重たい処理を訪問者のアクセスから分離し、サーバーとのコンビネーションで非同期に処理させる方法を探ってみました。

続きを読む