実践GitHub Pages運用のユースケースとワークフローの詳細 | ゆっくりと…
前回、GitHub Pages 活用の概要を書きましたが、実際に運用していくと、master と gh-pages をどう使い分けるか、また両者の同期をどう行うかなど、いくつかの課題が浮かび上がってくると思います。 そこで今回は、実際に GitHub Pages 上で運用されている Dive Into HTML5 をよく知る立場から書かれた記事 「GitHub Pages Workflow and deleting git’s `master` branch – Oli.jp」 の翻訳を中心に、関連するいくつかの記事から、ユースケースと運用のシナリオ、及びそれに応じたワークフローをまとめてみました。 以下は、その参考記事です。 Git post-commit hook to keep master and gh-pages branch in sync by Paul Irish 2011
意外と要注意 HTML5データ属性とjQuery Data APIの関係まとめ | ゆっくりと…
前の記事「HTML5でモダンブラウザのCSS3バグを回避するためのハック方法」に関連して、jQuery で HTML5 データ属性にユーザーエジェント文字列を格納する方法を調べていました。その結果、ちょっと整理をしておいた方が良いかなと思う点を共有したいと思います。 ご存知の方も多いと思いますが、jQuery には .data() や jQuery.data() という、DOM 要素に データ を紐付けて記憶しておく仕組みが元々ありました。jQuery 1.4.3 からは、 API レベルでの 親和性 が考慮された形で HTML5 data-* 属性を取り込む仕様が導入されました。 HTML5 時代では、クライアント・サイドで実行されるコード量も増え、データ属性を扱う機会もちょくちょく出てくるのではないでしょうか。そこで今回は、 HTML5 data-* 属性のおさらい jQuery Da
ブラウザ動作の理解－リフローとリペイント及びその最適化 | ゆっくりと…
ブラウザ動作の理解の2回目です。今回はレンダリング・ツリーの更新に絡む、リフロー （要素の大きさ、位置などの再計算） とリペイント （描画） に関する解説を、「High Performance Web Pages – 20 new best practices」 の著者 Stoyan Stefanov のブログエントリーから 「Rendering: repaint, reflow/relayout, restyle」 を翻訳してお届けします。 同記事は、前半がリフローとリペイントに関する解説と、表示レスポンスを向上させるためのスタイル変更に関する Tips、後半は dynaTrace AJAX Edition と SpeedTracer を使った IE および Chrome の描画パフォーマンスの計測の解説で構成されてる、長い記事となっています。 今回はその前半部分をご紹介します。 レンダ
ブラウザ動作の理解－レンダリングの負荷を測る | ゆっくりと…
転勤・単身赴任というライフ・イベントがあり、すっかり更新が止まっていましたが、前回 に続き、「Rendering: repaint, reflow/relayout, restyle」から後半のレンダリング負荷を測るツールの使い方をお届けします。記事中の リフロー や リペイント といった用語は、前回記事「用語の定義」 を参照してください。 元記事は初稿が2009年12月でツールのバージョンも古いため、現時点の最新バージョンで記事を再構成しています。また実行環境によって観測結果が異なるため （非力なマシンの方がレンダリング負荷の割合が高いけど、サンプルとしては分かりやすい）、以下に本記事で試した環境を記しておきます。 dynaTrace AJAX Edition バージョン：Version: 2.1.0.603, built on 2010-12-15 ブラウザ、PC：IE8 / Wind
CSS/JavaScriptのAsynchronous Loadingをめぐる熱い論議 | ゆっくりと…
2011年2月21日 追記 $script も新規参戦してきました。高々 643 バイトで、非同期読み込みや依存性の制御などができるそうです。いずれ紹介したいと思います。← 「新参の超軽量JavaScript非同期ローダー3種を徹底比較」で紹介しました！ これらのローダーのうち、LABjs の作者が 「On Script Loaders」 で HeadJS と ControlJS について意見をしていて、面白そうです。そのうち日本語訳や各ローダーの比較を行ってみたいと思います。 ローディング・スクリプトをめぐる議論 さてさて、本エントリーの本題は前述のローダーではありません。「Prefer asynchronous resources」 や Google Analytics のスニペット に示されているような、ローディング・スクリプトの変遷をまとめてみます。 これらのスクリプトのごく初期は
ブラウザ動作の理解－レンダリングツリーの構築と描画のタイミング | ゆっくりと…
HTML5 の Web Worker やら GPU でハードウェア・アクセラレートされる IE9 のレンダリングなど、今年もブラウザの進化が激しくなりそうですネ。一方でフロント･エンド改善によるページ表示の高速化 Tips や Hack も百花繚乱、出尽くした感がありますが、やはり原理原則を知らないと 「どれが正しくて筋が良いか」 中々判断が効かないと思いませんか？ そこで最も基本的な 「ページの読み込みから表示まで、ブラウザって何をどうやってるの？」 を理解していきたいなと思っています。 一番の厳密かつ王道は、ブラウザ間の違いを極力少なくするように注意深く書かれている HTML5 の仕様書 を理解だと思いますが、イキナリではハードルが高いので、まずは周辺を漁っています。そんな中から、ちょっと古いですが、2004年5月の記事 「Testing Page Load Speed」 を今回、翻訳
ページ読み込み時間を短縮するJavaScriptローダー：LABjs | ゆっくりと…
ブラウザは通常 Web サイトを訪れたとき、CSS や画像などのページ要素を幾つか並列で読み込みますが、JavaScript ファイルを読み込んでいる最中は、（JavaScriptやスタイルシート以外の） 他要素の読み込みをブロックします。それゆえ Yahoo! の 「Best Practices for Speeding Up Your Web Site」 では、それ以上他の要素を読み込む必要のないページ下端に JavaScript を置くことを推奨しているわけです。 これに対し 「ハイパフォーマンスWebサイト―高速サイトを実現する14のルール」 （今は35のルールですが） の著者 Steve Souders が Non-blocking JavaScript、つまり他のページ要素をブロックしないファイルの読み方を提唱しています。LABjs は氏の監修の下で作成されたオープンソースの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
