ページ上でずっと動いているsetTimeout、setInterval、requestAnimationFrameを見つけてパフォーマンス改善する
ページ上でずっと動いているsetTimeout、setInterval、requestAnimationFrameを見つけてパフォーマンス改善する 複雑なウェブアプリケーションになってくると、1つのページで複数のTimerなどを回すことがあります。 例えば、Twitterのようなアプリならば、ポーリングで更新するためにsetInvervalのようなタイマーを回します。 また、ゲームなどCanvasで描画を行うアプリケーションならば、メインループをrequestAnimationFrameで回します。 このように色々なタイマー系がありますが、アプリが多機能になっていくと色々なタイマーが同時に動くようになっていきます。 特に問題がなりやすいのが表示中だけタイマーを回すコンポーネントです。 よくあるのが次のようなmount時にtimerを開始して、unmount時にtimerを停止するコンポーネ
Webフロントエンドに従事するお前らはいい加減高頻度イベントとレイアウトとスタイリングの付き合い方を考えろ - Qiita
もうなんかこの際マジで言わせていただくんですけど、知ってるか知らないか分かりませんが世の中にはすごい頻度で呼ばれうるDOMイベントって言うのがいくつかあるわけですよ 例えば scroll mousemove, touchmove devicemotion 辺りですよ。 で、高頻度で呼ばれるって言うことは必然的に処理量が増えるって分かりますよね？？？？？while(1) {}じゃないとはいえUIスレッドに十分影響を与えうる頻度で呼ばれる訳です。分かりますよね？？？？？？？？ そうなると当然そのイベント内で重い処理を行えば人間が認識できるレベルでのレスポンス遅延が起きるっていうのはご理解できますよね？ 重い処理っていうのはまぁ想像出来るとは思うんですが例えばよくあるのが DOMのレイアウトプロパティへのアクセス offsetTop、offsetLeft、offsetWidth、offsetHe
モバイル環境でDOM挿入する時innerHTMLとappendNodeどっちが速いの？という話 - mizchi's blog
面白かったので紹介。 Mika Raento's Tech Blog: innerHTML vs appendNode vs DocumentFragment - Optimizing bulk DOM operations for mobile まあ正確に言うとDocumentFragmentの比較もあるんだけど、ベンチ上appendNodeと違いはないのでタイトルからは割愛。 結論 普通はappendNodeが速いけど、要素数を多くすると徐々にinnerHTMLに分がでてくる。均衡点は1000ノード。 ベンチマーク 上の記事から図を引用 これは自分の予想だけど、要素が多くなるにつれappendNodeのDOMとのネイティブのブリッジを経由するのがボトルネックになる。innerHTMLはパーサのコスト+appendNode一回分。 誰が気にするの テンプレートエンジン作者は気にすると良さ
Webフロントエンドパフォーマンスチューニング
Webフロントエンドのパフォーマンスチューニングについて全体的な話。javascript、Chrome DevToolsの紹介、ボトルネック、ポイントなど。
High Performance JavaScript 2011
For much of its existence, JavaScript has been slow. No one complained until developers created complex web applications with thousands of lines of JavaScript code. Although newer JavaScript engines have improved the situation, there’s still a lot to understand about what makes JavaScript slow and what you can do to speed up your code.Read less
forEach色々とベンチマーク - os0x.blog
cho45さんがCodeReposにあげていたJSEnumeratorに付随していたベンチマークでちょっと遊んでみました。 肝心なことを書き忘れていた。はっきりと差が出ているのは、10回のループをさらに1000回ループさせているからで、大抵の場合はどのメソッドを使っても体感できるほどの差は出ないと思います。 jQuery、prototype.js、MochiKit、fLDR、JSEnumeratorなどで使われているforEach関数の速度比較です。recursive eachは一応オリジナルです。 以下、実験ページ http://ss-o.net/jsenumerator/benchmark/10.html http://ss-o.net/jsenumerator/benchmark/100.html 結果 とりあえずWindowsのみmacは後で面倒だか、じゃなくて、windowsと大
Extreme JavaScript Performance
Talk given at http://jsconf.eu 2009. You serve up your code gzipped. Your caches are properly configured. Your data (and scripts) are loaded on-demand. That's awesome—so don't stop there. Runtime is another source of slowdowns, and you can learn to conquer those, too. Learn how to benchmark your code to isolate performance issues, and what to do when you find them. The techniques you'll learn rang
2分でわかる uupaa.js の サクサク :: handsOut.jp
スライド1: 2 分でわかる uupaa.js~ Speedy ~uupaa.js@gmail.com スライド2: 今日のテーマは「サクサク」 スライド3: サクサクにするには1. 名前解決コストを減らす2. ガベージレス3. Hash で評価4. Hash の事前生成5. イベントハンドラの軽量化 スライド4: 1. 名前解決コストを減らす• スコープ内に alias を作成し、そちらを参照する– STYLE B は JIT 非搭載ブラウザで特に効果的例: IE6で 6%, IE7,IE8で 9%, Firefox3で 12%, Opera10で 3% 高速化例: 関数の alias を用意すると IE6で 2.7倍 高速化// 元のコード (STYLE A)var _regexp = /regexp/;(function() {(function job() {for () {
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
