カテゴリー別アーカイブ: XHTML/CSS

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部では、戦術に基づいた「実践」について書いてみたいと思います。

続きを読む

そのコード、本当にjQueryが必要ですか?ネイティブ関数の代替Tips集

sitepoint から「本当にjQueryが必要ですか?」とタイトルのついた3本の記事を紹介します。

言うまでもなく著者の Craig Buckler さん の趣旨は、「jQueryを使うのは止めよう」ではありません。ネイティブ関数で代替えできるのは、古い IE のサポートが必要なく、ごく簡単なケースに限られます。その代わりに得るものは「速さ」です。そこで、どの程度「速い」のかを所々 jsperf の結果で補ってみたいと思います。

また JavaScript 初学者の人も、jQuery が内部でどう苦労しているのか知るのも良いと思います。私自身の勉強も兼ね、その他の情報も色々と補っていますので、良かったら見ていって下さい 😀 。

続きを読む

サイト速度とonload再考

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

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

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

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

続きを読む

jQueryプラグインのオプションとHTML5 data-*属性でハマった時に幸せになれるかもしれないまとめ

html5 data parser

意外と要注意… なんて記事を書いておきながら、実際に HTML5 のカスタム・データ属性にオプションを指定する jQuery プラグインを作っていて、かなりハマってしまいました。

data-* 属性に書いた複雑なオプションを jQuery Data API で処理するには、JSON で指定しなくちゃダメなんですネ。ちゃんと ドキュメント にも書いてありました 😉 。

ということで、「もっと簡単に記述できるようにしたい!」を叶える 簡易な data-* 属性パーサー を作りましたので、ここに発表します。

ついでに data-* を使った jQuery オプション指定のユースケースを整理し、その実装方法をまとめてみたいと思います。

続きを読む

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

iOS Safari

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

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

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

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

続きを読む

3rdパーティー製スクリプトによるフロントエンドSPOFを検出するChrome拡張

twitter down

6月22日未明、Twitter のサーバーがダウン し、全世界でサービスが停止しました。一部マニアの方々は、動いていた ケータイ用サーバー から この状況を楽しんでいた (?) ようですが、OMG..twitter was down….closest thing to living without oxygen for most of us…. (なんてこった、オレたちに酸素なしで生きろっていうのか) という声に代表されるように、世界各地で悲鳴が上がったようです。

さて純正の Twitter ウィジェット を貼っているあなたのサイトは、この障害でページが真っ白になったり途中で引っかかったりせず、無事にコンテンツを提供できたでしょうか?

ということで、前回 と同ネタですが、こういった フロントエンドの単一障害点SPOF) をより簡単にチェックできる Chrome エクステンション SPOF-O-Matic を紹介します。

続きを読む

ブラックホールサーバーによるフロントエンドSPOF分析のすすめ

SPOF と聞いて、すぐに 「あぁ、Single Point of Failure (単一障害点) のことネ」 と分かる人は、まじめにシステム工学を勉強した人か、ハードウェアを含む情報システム設計に知見のある人だと思います。

では、「フロントエンド」 が付くと、いったい何を指すのでしょうか?

現代の Web サイトの多くは、自分が管理する (あるいは借りている) サーバーで全てのサービスを賄うのは、Yahoo や Google などの超大手以外ではほとんどないんじゃないかと思うほど、サードパーティが提供するサービスを取り込んでいると思います。Facebook、Twitter、flickr、YouTube はもちろん、jQuery などのライブラリ CDN、WebFont、アクセス解析なんかもありますネ。

もしこういったサービスを提供するサードパーティのサーバーがダウンした時、あなたのサイトは、その主たるコンテンツをちゃんとユーザーに提供できますか? というのが今回のお題です。

さらには、こういった単一障害点を分析し対策を打っておく事が、実はサイトのボトルネックを把握し、レスポンスを上げる事にもつながるという話をしたいと思います。

続きを読む

document.writeを使った遅いブログパーツ(例えばzenback)を非同期化してサイトを高速表示する方法

広告やソーシャル系のサードパーティー製ブログパーツを張りたいんだけど、サイトの表示速度が遅くなるのって我慢なりませんよネ。こういったブログパーツの多くが JavaScript で作られています。自サーバーに設置したスクリプトならまだ手の打ちようはあるし、本サイトでも JavaScript 読み込みを高速化するための非同期化ネタを幾つか扱ってきました。例えば Google Analitics の非同期トラッキングスニペットLABjsHEAD JS などの非同期ローダーが有名なところでしょう。

ところが困ったことに、こういったサードパーティ製スクリプトに document.write が使われていると、Google Analitics のようなテクニックや非同期ローダーでは、ほとんどの場合でページが白紙となってしまい使えません。Twitter や Facebook など超有名どころは既に自社のブログパーツを非同期化していますが、まだまだ document.write が現役で幅を利かせているのではないでしょうか。

HTML (ドキュメント)、スタイルシート (見た目)、JavaScript (振る舞い) という3つの言語による分業や、セマンティックなマークアップ、DOM ベースのスクリプティングなどが主流の今日で、またページの表示速度が遅くなるとコンバージョン率を悪化させるという話は有名なのに、本当に困ったことです (タイムリーなことに、スクリプトに document.write を使うのはやめよう というエントリーが、先日 Steve Souders によってポストされました)。

ということで、今回は document.write を使ったスクリプトにも使える、古くて新しい非同期化の方法を紹介したいと思います。

2012年10月10日 修正

Friendly Iframe の具体的なサンプルコードを追記し、また記事中での一貫性を持たせるため、他のコードも若干修正しました。

2012年8月4日 修正

非同期読み込み遅延読み込み を少し厳密に区別しました。

2012年4月9日 追記

IE での動作確認が出来ましたので、記事の後半を大幅に修正しました。

続きを読む

最近海外で流行りのTwitter,Facebook,Google+1,Analyticsをまとめる非同期スクリプトにはてなを加えてみた

ひょんなことから normalize.css のページを覗いていたら、Google Analytics、Google +1、Twitter、Facebook の各 JavaScript をまとめて非同期で読み込んでいるスクリプトが使われているのを見つけました。

CSS/JavaScriptのAsynchronous Loadingをめぐる熱い論議」 でも書きましたが、スクリプトの非同期読み込みは、Google Analytics のコードスニペット で一応の決着を見た感じで (実は、標準化を巡って第2ラウンドが始まってはいますが…)、今や Google+1 はもちろん、Facebook も同様の手法を推奨しています。

調べてみたら、「それなら Twitter のスクリプトだって同じように読めばいいじゃないか」 という感じでどんどん まとめスクリプト の改良が進んできたようです。

我が日本としてはこれに 「はてな」 を加えるしかない!、ということで作ってみましたので、公開したいと思います。

続きを読む