Build with Chrome Learn how Chrome works, participate in origin trials, and build with Chrome everywhere.
Hello, (strange) world The Google homepage is a fascinating environment to code within. It comes with many challenging restrictions: particular focus on speed and latency, having to cater to all sorts of browsers and work under various circumstances, and… yes, surprise and delight. I’m talking about Google doodles, the special illustrations that occasionally replace our logo. And while my relation
jsPerf — JavaScript performance playground What is jsPerf? jsPerf aims to provide an easy way to create and share test cases, comparing the performance of different JavaScript snippets by running benchmarks. For more information, see the FAQ. Create a test case Login with GitHub to Create Test Cases
GoogleがWeb全体のスピードアップにいよいよ本格的に着手, 一社だけではできないと強調 からリンクのあった、 http://code.google.com/intl/ja/speed/articles/optimizing-javascript.html が日本語かと思ったら日本語じゃなかった・・・・。 いやー、意外とというか文字列については、全然知らんかった。 Closureって便利だし、「おぉ〜俺って使ってるジャン」みたいな気になれるからついつい使っちゃうんだけど、高コストなのね・・・・。反省。 ということで、超適当翻訳。どっかの誰かが書いてるかも。 前おき 著者: Google Chromeのエンジニア Gregory Baker, Software Engineer on GMail & Erik Arvidsson 推奨される経験:JavaScriptの実践的な知識 クライ
と言っても、前々から作っているセレクタ関数が依存無しで簡単に切り出せそうだったから、切り出しただけです。 http://kquery.if.land.to/ksk.js 動作ブラウザはIE5.5以上です。これを導入するとIE5でも動作します。 使い方 ksk("div"); // divタグを取得します ksk("p", document.body); // body要素以下のpタグを取得します ksk("a", document.getElementsByTagName("p")); // p要素以下のaタグを全て取得しますセレクタはCSS3のやつを大体実装しています。最大の特徴は複数の要素以下の探索に対応していることです。kQueryが実際に完成したら、$(selector).find(selector)とかは高速かつ正確に処理できる予定です。 既知のバグとか 親要素のチェックが甘いで
2009-11-12 ナビ子記法について追記しました 本文 今日は、amachangさんの記事 http://d.hatena.ne.jp/amachang/20071010/1192012056 を 1mm だけ掘り下げ、IE 以外のブラウザでも document へのアクセスを速くする方法がないか、色々試してみます。 # 記事自体はずいぶん前に書き上げてたけど、公開するの忘れてたんだな。 C系を追加しました。C系は「ネストしたスコープからグローバル変数にアクセスするとどうなるか?」がテーマです。 試したこと 以下は様々な方法で document へのアクセス速度を計測します。 A系では、非日常的な方法で測定し、B系では実際の用法に近い形で測定します。C系では何重にもネストしたスコープから、グローバル変数にアクセスするとどうなるかを測定します。 A系 A0 は、素の document に
はてブ閲覧時のリソース不足 長時間はてブを利用していると添付の画像の様に画面がぐちゃぐちゃになる事が頻繁にあります。 他のアプリのウインドウも激しく乱れ新たにプログラムを起動出来なくなります。 システムリソースが不足した時と酷似しています。 NT系ではDesktop Heapがリソースに相当するとの事なので、MSのDesktop Heap Monitorを導入しましたがUsed Rateが30~60%程度でも件のリソース不足のような挙動になります。 他のアプリの起動し過ぎの場合にはUsed Rateが95%以上でないと件の状況にならないようです。 その時にはフォントが大きく表示される等の挙動がありますが、長時間のはてブ閲覧時にはありません。 そこでお聞きしたいのは、はてブのページを沢山閲覧した時に特有のこの現象がDesktop Heapが原因でないのなら何が原因かという事です。 判りやすい
JavaScriptの部分は というわけでid:amachangに任せましょう。 というわけでそれ以外の部分でいったいどこが重いのか 何が重いの?ということで重たい箇所を分析していきましょう。 IBM PageDetailer 解析ツールとしてIBM PageDtailerを利用します。 alphaWorks Community 解説するよりも見てもらうほうが早いと思うのでさっそく使ってみるよ。 ちなみに上記ソフトのダウンロードにはIBMアカウント(無料)が必要なので、使いたい人は登録しよう! http://b.hatena.ne.jp/HolyGrail/ の結果 こんな感じのグラフが出てきます。 では、詳細を見てみましょう。 このグラフですが、長い部分が http://b.hatena.ne.jp/HolyGrail/ のHTMLそのもののロード時間になっています。 内訳としては 濃い
Web2.0としてくくられるタイプの各種ネットサービス、いわゆるウェブアプリは以前とは比較にならないほど動的生成されるものが多く、結果としてものすごい負荷をシステムにかけるわけです。 というわけで、海外におけるデジカメ画像共有サービスの代表的なものである「Flickr」の開発者がJavaScriptを高速化する手法について解説しています。 Vitamin Features >> Serving JavaScript Fast 手順を分割して簡単にしてみたり、キャッシュを使ったり、転送量を圧縮して帯域を節約したりいろいろあるようです。なお、GIGAZINEはキャッシュシステムを採用して有効活用することで負荷を現在、当初の12分の1に抑えています。 また、こっちはリバースプロキシによる高速化手法。 ViSolve.com - Squid Support Service Apacheのモジュール
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く