特集：GitHub通のためのリニューアルまとめ – ビジネスを成功に導く5つの仕掛け | ゆっくりと…
これまでも サービスAPI の更新や、それに伴う UI の変更など、小刻みな機能向上が図られていましたが、昨年11月、GitHub の ヘッダ、フッタが新しくなった のを皮切りに、12月には Gist のリニューアル と GitHub トップページのリニューアル が立て続けに行われました。 また今年1月には、ユーザー数が、アカウントベースで300万人を超えた そうです。 小さくかつ素早く、不断のサービス向上を図る姿勢が、ここまでユーザーを惹き付けた理由なのでしょう。 一方、公式ブログ を追いかけていくと、単に Git のリポジトリ・サーバーとして便利で使い易くする以上に、「自然に人が集まる魅力的なコミュニティ」を目指し、「誰もが気軽に参加できるオープンソース・コミュニティを創る」という意気込みのようなものを感じました。 人が集まれば、それだけビジネスの機会も増えるというワケです。 そこで今
サイト速度とonload再考 | ゆっくりと…
単にウケ狙いなら「革新的！GAのページ平均読み込み時間を劇的に速くする方法」とか「もう3rdパーティーに邪魔させない、超高速スクリプト読み込み術」（笑）とかの煽りタイトルを付けるところですが、今回はもっと本質的なことを論じてみたいと思います。 「プログレッシブレンダリングでUXを向上させるJS非同期読み込みのベストプラクティス」では、スクリプトの読み込みと実行を window.onload 対象から切り離し、見た目のページ速度を速くする方法について書きました。この方法は既存のスクリプトを書き換える必要があるため、Stoyan Stefanov によって 実験的に実装された Facebook SDK か、自前のスクリプトにしか適用できませんでした。 しかし今回、Hatena や Twitter、Pocket、Disqus など、他の 3rd パーティ製スクリプトにも適用できる方法 − “進化
プログレッシブレンダリングでUXを向上させるJS非同期読み込みのベストプラクティス | ゆっくりと…
本ブログでは、サイトの高速化に直結する「JavaScript 非同期読み込み」の話題を多数取り上げてきました。タイトルに釣られてこの記事を見てくれている方なら Google Analytics の非同期コードスニペット はご存知でしょうし、規模の大きいサイトやアプリ用に RequireJS などのフレームワークを使っている方もいるでしょう。 GA も RequireJS も、動的に生成したスクリプト要素を DOM に埋め込む「DOM 挿入法」が用いられています。さらに遡れば、Steve Souders が 2009年4月の記事 ノン・ブロッキングなスクリプト読み込み で、6つの手法に分類しています。 果たしてこれらの方法は、サイトの高速化にとってベストなのでしょうか？ 答えは2012年12月の海外記事にありました。そこで本エントリーでは、日本ではほとんど取り上げられていない Frame i
Respond.jsとレスポンシブWebデザインをめぐるベストプラクティス議論 | ゆっくりと…
2012年2月、Modernizr 2.5 の カスタム・ビルダー から Respond.js が外されました。理由は、HTML5 Boilerplate （以下 H5BP） コミュニティでの決定です。Respond.js は、IE8 以下などのメディアクエリ未対応なブラウザにもその代替え機能を提供するスクリプトで、レスポンシブ Web デザイン を支えるスクリプトとして、H5BP に長らく （8ヶ月） 採用されてきた経緯があります。 ではなぜ、Respond.js は外されたのでしょう？ 今回は、その決定を下した長～い議論 Issue #816: Revert mobile-first media queries and remove respond.js から、ベスト・プラクティスの要点と、Paul Irish の考える H5BP の理想像を読み解いてみたいと思います。 ヘタクソで読み
document.writeを使った遅いブログパーツ（例えばzenback）を非同期化してサイトを高速表示する方法 | ゆっくりと…
広告やソーシャル系のサードパーティー製ブログパーツを張りたいんだけど、サイトの表示速度が遅くなるのって我慢なりませんよネ。こういったブログパーツの多くが JavaScript で作られています。自サーバーに設置したスクリプトならまだ手の打ちようはあるし、本サイトでも JavaScript 読み込みを高速化するための非同期化ネタを幾つか扱ってきました。例えば Google Analitics の非同期トラッキングスニペット や LABjs、HEAD JS などの非同期ローダーが有名なところでしょう。 ところが困ったことに、こういったサードパーティ製スクリプトに document.write が使われていると、Google Analitics のようなテクニックや非同期ローダーでは、ほとんどの場合でページが白紙となってしまい使えません。Twitter や Facebook など超有名どころは既
jQueryのDeferredとPromiseで応答性の良いアプリをー実践編 | ゆっくりと…
前回 は、「Creating Responsive Applications Using jQuery Deferred and Promises」 の記事と jQuery のリファレンスを翻訳し、Deferred の解説をお届けしました。が、今一歩、Deferred オブジェクトの うれしさ をお伝えできていなかったように思います。今回はその反省をふまえ、単なる翻訳ではなく、元記事の文脈に沿って、Deferred オブジェクトをどのように使うと／何がうれしくて／どうしあわせになるのか、私が学習して得た事をお伝えしたいと思います。 今回は、4本の jsfiddle を記事に埋め込んでいます。jsfiddle 上で自由に編集してテストしてもらえばうれしいのですが、4本すべて実行すると1.4MBものリソースを読み込む事になり、ブラウザに優しくありません。すぐに タブや をクリックせずに、 タブ
CSS/JavaScriptのAsynchronous Loadingをめぐる熱い論議 | ゆっくりと…
2011年2月21日 追記 $script も新規参戦してきました。高々 643 バイトで、非同期読み込みや依存性の制御などができるそうです。いずれ紹介したいと思います。← 「新参の超軽量JavaScript非同期ローダー3種を徹底比較」で紹介しました！ これらのローダーのうち、LABjs の作者が 「On Script Loaders」 で HeadJS と ControlJS について意見をしていて、面白そうです。そのうち日本語訳や各ローダーの比較を行ってみたいと思います。 ローディング・スクリプトをめぐる議論 さてさて、本エントリーの本題は前述のローダーではありません。「Prefer asynchronous resources」 や Google Analytics のスニペット に示されているような、ローディング・スクリプトの変遷をまとめてみます。 これらのスクリプトのごく初期は
defer/asyncチェックツールを作りブラウザ対応状況を確認してみた | ゆっくりと…
ちょっと前に 「scriptのdefer/asyncを理解し、ページの高速化方法を探る」 というエントリーを書きましたが、はてなのブックマーカー edvakf さんから 「Opera は defer も async も対応してないはず」 というご指摘を頂きました （edvakf さん、ありがとうございます）。 こちら と こちら （2012年11月16日：Google のドキュメントが削除されました） の表を 「対応状況」 としてそのまま流用してしまったのが失敗でした。英語をよく読めば、You can use the defer/async attribute on the following elements と書いてあります。つまり 属性は使えるけど、動作は別 とも読めるわけで…。 ということで、「defer/async チェッカー （仮）」 を作ってリベンジすることにしました。 1.
ブラウザ動作の理解－レンダリングの負荷を測る | ゆっくりと…
転勤・単身赴任というライフ・イベントがあり、すっかり更新が止まっていましたが、前回 に続き、「Rendering: repaint, reflow/relayout, restyle」から後半のレンダリング負荷を測るツールの使い方をお届けします。記事中の リフロー や リペイント といった用語は、前回記事「用語の定義」 を参照してください。 元記事は初稿が2009年12月でツールのバージョンも古いため、現時点の最新バージョンで記事を再構成しています。また実行環境によって観測結果が異なるため （非力なマシンの方がレンダリング負荷の割合が高いけど、サンプルとしては分かりやすい）、以下に本記事で試した環境を記しておきます。 dynaTrace AJAX Edition バージョン：Version: 2.1.0.603, built on 2010-12-15 ブラウザ、PC：IE8 / Wind
ブラウザ動作の理解－リフローとリペイント及びその最適化 | ゆっくりと…
ブラウザ動作の理解の2回目です。今回はレンダリング・ツリーの更新に絡む、リフロー （要素の大きさ、位置などの再計算） とリペイント （描画） に関する解説を、「High Performance Web Pages – 20 new best practices」 の著者 Stoyan Stefanov のブログエントリーから 「Rendering: repaint, reflow/relayout, restyle」 を翻訳してお届けします。 同記事は、前半がリフローとリペイントに関する解説と、表示レスポンスを向上させるためのスタイル変更に関する Tips、後半は dynaTrace AJAX Edition と SpeedTracer を使った IE および Chrome の描画パフォーマンスの計測の解説で構成されてる、長い記事となっています。 今回はその前半部分をご紹介します。 レンダ
HTML5 Boilerplate, Initializrをこれから使う人が押さえるべき5つの原則 | ゆっくりと…
boilerplate とは、「再利用を意図した標準的な文例集」 だそうです。 Paul Irish が中心となり構築されてきた HTML5 Boilerplate は、その名の通り HTML5 でサイトを構築するためのテンプレート、さらにはフレームワークをも含む内容となっており、その特徴は次のように語られています。 HTML5 Boilerplate は、HTML5 を扱う上で必要な数多くの機能強化を他のベスト・プラクティスの数々と組み合わせることで、最小限の先行投資でプロジェクトの磐石な基盤を提供します。 2011年02月08日 HTML5 Boilerplate を使用して Web 開発を容易に始める | IBM developerWorks より。 HTML5 Boilerplateをベースにすることで最初からベストプラクティスが適用されたサイトやページを構築できるという特徴がある
実践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
GitHub Pagesホスティングサービス（ほぼ）完全活用ガイド | ゆっくりと…
GitHub がオープンソースの場として魅力的な理由は、Git という優れた分散・協調型リビジョン管理システムのリポジトリー・ザーバーとして誰でも利用できるということはもちろん、README などのドキュメント生成機能やコメンティング機能、問題のトラッキング機能など、Git を補助し、オープンな分散・協調開発を支えるサブシステムが充実している点が挙げられるでしょう。無料でもかなりのことができるのに、ビジネスとしてもちゃんと成立している理由はこんなところにあるように思います。 ただ、同種サービスの Google Code や Bitbucket と決定的に異なり、GitHub の最大の魅力となっているのは、GitHub Pages という1種のホスティング・サービスではないかと思います。成果物をただずらずらと味気ないページに並べるのではなく、趣向を凝らした紹介ページを自由に作り、プロジェクト
脱GitHub初心者を目指す人のREADMEマークダウン使いこなし術 | ゆっくりと…
README がキチッと書かれているプロジェクトって、どんなに小さくても立派に見えますよネ。 GitHub の場合、大抵はマークダウン記法で書かれた README.md とか README.markdown とかいう名前のファイルが、HTML に変換 （マークアップ） されて表示されていることはご存知でしょう。 マークダウン記法自体はとても簡単なのですが、GitHub では GitHub Flavored Markdown （略して GFM） という GitHub 用にアレンジされたマークダウン・エンジンが採用されていて、一般のマークダウン・エディタでチェックしてからコミットしても、意図通りの見た目にならないことが多々あります。私 （もちろん GitHub 初心者です！） の場合、README ファイルだけで10回以上もコミットしてしまいました。「マークアップ （レンダリング） を気にして
jsFiddleをとことん楽しむために知っておくと良い15の事 | ゆっくりと…
「fiddle」 には、「いじくる, もて遊ぶ」 とか 「暇・時間をつぶす」 などの意味があるようです。「jsFiddle」 はご存知の通り、HTML + CSS + Mootools、jQuery、Prototype、Dojo などの各種 JavaScript フレームワークで、遊んでみようというサイトです。日本には、「jsdo.it」 という、楽しいサイトもあるのですが、jsFiddle はまだαバージョン。次のβバージョンでは機能追加が数多く予定されており、個人的には期待大なのです。また jsdo.it にはない機能もありますので、必要に応じて使い分けるのが吉だと思います。 今回はそんな魅力が伝えられるよう、まとめてみたいと思います。 1.Firebug Liteの組み込み クロス・ブラウザのチェックも含めて、console 系のデバッグ出力 を使いたい場合、Firebug Lite
jQueryのDeferredとPromiseで応答性の良いアプリをー基本編 | ゆっくりと…
jQuery 1.6 が既にリリース されていますが、1.5 で追加された Deferred を勉強する意味で、Script Junkie から Creating Responsive Applications Using jQuery Deferred and Promises を翻訳してみましたので、共有したいと思います。著者の Julian Aubourg は、jQuery のコアチーム・メンバーとして、Ajax モジュールの書き換えと Deferred 導入を指揮した方だそうです。 記事の途中、各メソッドの説明部分は、jQuery ドキュメントの翻訳に差し替えていますので、リファレンスとして使ってもらうのも良いかと思います。 Deferred や Promise は、概念や用語が少々分かりにくいところがあるかと思いますので、読んでくださった方の、少しでも理解の助けになれば幸いです
"遅いブログパーツを高速表示する方法"を検証する | ゆっくりと…
かん吉さんの記事 「遅いブログパーツを高速表示する方法」、すばらしいですネ。アフィリエイトをやっている人にとっては、とても興味を引く記事だと思います。ですが、紹介されているスクリプトは、中級以上の方が対象 とあるように、私のような初級者が知っておくべきことがあるはずです。 そこでまず私自身が中級者以上となるために、過去3回に渡り自分なりにブラウザの動作を勉強してきました。 ブラウザ動作の理解－レンダリングツリーの構築と描画のタイミング ブラウザ動作の理解－リフローとリペイント及びその最適化 ブラウザ動作の理解－レンダリングの負荷を測る そこから見えてきたのが、レンダリング・ツリー の役割りです。ブラウザの本質は、ドキュメントとその見た目 （ビュー） の管理です。前者は、文書自体やその構成の管理に責任を負い、後者は、描画について責任を負う。そして、両者のコラボレーションによりユーザーに情報を
Syntax Highlighter 系プラグインの比較と高速化 | ゆっくりと…
このサイトではHTMLやCSS、PHPなどのコードを紹介するため Syntax Highlighter をよく使います。この時気になるのがページの読み込み開始から表示の終了までにかかる時間ではないでしょうか？ 勿論環境やプラグインの種類にもよりますが、コード部分に <pre> タグが適用された状態で一旦表示され、その後きれいに再描画されるのを目撃したことがあるでしょう。このような振る舞いは見た目にもあまり好ましくなく、サイトレスポンスの遅さを目立たせます。 そこで今回は WordPress.org に多数登録されている Syntax Highlighter 系プラグイン を、デザインや機能に加え、ページ要求から表示までのレスポンスという観点で比較・整理をしてみたいと思います。 そして最後に、ブラウザでのレンダリング速度を改善する提案をしてみたいと思います。 機能とスタイルによる分類 Syn
scriptのdefer/asyncを理解し、ページの高速化方法を探る | ゆっくりと…
Yslow ルールでは、スクリプトはページの最後尾、つまり </body> 直前に置け、と言っています。なぜなら、スクリプトの読み込みや実行により、他のページ要素の読み込みやレンダリングがブロックされてしまうからです。 一方、古くは IE4 の時代から Microsoft はこの問題に対処するため、defer 属性という独自の解決策を実装してきました。これは HTML 4.01、XHTML 1.0、1.1 で仕様として採用され、HTML5 にも発展する形で引き継がれています。 IE 以外のブラウザも既に対応されており、IE の独自仕様という色合いが濃かった従来と異なり、これからは広く利用されていくのではないかと思います。 下のビデオは、スクリプトの位置と defer 属性のあり／なしによる、ページの読み込み／表示速度の違いを Pagetest.com でテストしてみたもので、明らかな差異が
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
