Introduction · Webフロントエンド パフォーマンス改善ハンドブック
Webフロントエンド パフォーマンス改善ハンドブック このパフォーマンス改善ハンドブックでは、ウェブアプリケーションにおけるフロントエンドのパフォーマンス改善について扱っています。 ダウンロード版 埋め込み動画を再生できないなど一部制限がありますが、ダウンロード版を配布しています。 PDF版 EPUB版 MOBI版 目的 このハンドブックでは過去に行った改善の事例を中心に紹介しています。 そのため、現在の最適な解決方法を提案するものではありません。 また、アプリケーションによっても最適な解決方法は異なります。 今回の事例ではViewライブラリにReactを使い映像再生プレイヤーなどある程度複雑な機能を持ったウェブアプリケーションのフロントを扱います。 具体的にはニコニコ生放送（以下「生放送」）で行った事例を中心に書かれています。 開発と平行して行われていたため、React 15から16の間
Mackerelにおけるフロントエンドのパフォーマンス改善の取り組み - Hatena Developer Blog
この記事は、はてなエンジニアアドベントカレンダー2016の14日目の記事です。13日は id:astj による『Perl 6 のモジュールエコシステムの話とモジュールを公開する話 (2016年12月版) - 平常運転』でした。 こんにちは。Mackerelチームでアプリケーションエンジニアをやっている id:itchyny です。 Mackerelは、同じ役割を持つホストを束ねた「ロール」、そしてロールを束ねた「サービス」というまとまりでホストを管理し、一覧性の良いグラフ画面を提供しています。 ロールあたりのホスト数、そしてサービスあたりのロール数が増えると、グラフの画面のパフォーマンスに大きく影響します。 Mackerelチームでは大規模なサービスでも快適にグラフを閲覧できるように、継続的に画面のパフォーマンスを改善してきました。 本記事では、Mackerelのフロントエンドのパフォーマ
left-padの文字列連結はクソではない - NullPointer's
例のleftpad, GCを虐めるためとかコンパイラの最適化を確認するために用意する、「無駄に一時オブジェクト量産するクソコードの典型例」みたいな実装なので、こんな小さい関数のために、信頼できない人のコードを、実装を見るでも無く、依存性追加してたってことで、— INADA Naoki (@methane) March 24, 2016 ここから始まる一連の、モジュールの依存性に関する議論はなかなか興味深いが、自分的に気になったのは以下の一節 GCを虐めるためとかコンパイラの最適化を確認するために用意する、「無駄に一時オブジェクト量産するクソコードの典型例」みたいな実装 ソースを見てみようか。 left-pad/index.js at 0e04eb4da3a99003c01392a55fa2fdb99db17641 · azer/left-pad · GitHub なるほど一見するとクソコー
Virtual DOMってどんだけ早いの？測ってみた - webとかmacとかやってみようか R
この記事は VirtualDOM Advent Calendar 2014 - Qiita の2日目です。 mizchi くんから誘われて軽い気持ちで参加したら、初日からえらくエモいエントリー(VirtualDom - なぜ仮想DOMという概念が俺達の魂を震えさせるのか - Qiita) でブルってます。 Virutal DOMとは、と言う話はしません。初日を見てください。いろいろ良いことあるみたいだけど、Virtual DOMってどんだけ早いの？知りたいですよね。 Elmの中の人が作ったTodoMVCのパフォーマンステストがあります。 いつものTodoMVCのデモで、100要素追加して、全て完了して、削除するというテストです。 「Run All」ボタンをクリックすると動きます。 http://evancz.github.io/todomvc-perf-comparison/ Virtua
Webフロントエンドに従事するお前らはいい加減高頻度イベントとレイアウトとスタイリングの付き合い方を考えろ - Qiita
もうなんかこの際マジで言わせていただくんですけど、知ってるか知らないか分かりませんが世の中にはすごい頻度で呼ばれうるDOMイベントって言うのがいくつかあるわけですよ 例えば scroll mousemove, touchmove devicemotion 辺りですよ。 で、高頻度で呼ばれるって言うことは必然的に処理量が増えるって分かりますよね？？？？？while(1) {}じゃないとはいえUIスレッドに十分影響を与えうる頻度で呼ばれる訳です。分かりますよね？？？？？？？？ そうなると当然そのイベント内で重い処理を行えば人間が認識できるレベルでのレスポンス遅延が起きるっていうのはご理解できますよね？ 重い処理っていうのはまぁ想像出来るとは思うんですが例えばよくあるのが DOMのレイアウトプロパティへのアクセス offsetTop、offsetLeft、offsetWidth、offsetHe
文字列結合のベンチマークをいろんな処理系でやってみた
The document contains results from various benchmark tests measuring the performance of different programming languages and implementations like Node.js, Java, Python, and others. It includes graphs showing the time taken to complete tasks like string concatenation and list operations. The benchmarks also compare just-in-time compilers and tracing JIT performance for some languages.
JavaScriptとCSSファイルのHTTPリクエストを最小限にし圧縮・キャッシュする -BoxJSとBoxCSS
ウェブサイトで使用する複数のJavaScriptとCSSファイルのHTTPリクエストを少なくし、圧縮・キャッシュするサービスを紹介します。 [ad#ad-2] 複数のJSファイルをまとめる -BoxJS 複数のCSSファイルをまとめる -BoxCSS 複数のJSファイルをまとめる -BoxJS BoxJSは一つのJSファイル（box.js）を利用し、モジュール式のローディングシステムで複数のJSファイルをロードできます。 BoxJS BoxJSの使い方 最初に、box.js(1.4kb)を外部ファイルとして指定します。 <script src="http://www.boxjs.com/box.js"></script> ロードするJSファイルを指定します。 Box('http://mywebsite.com/scripts/', [ 'plugins/jquery.js', 'plugi
「JavaScriptと性能についての本当の話」をしよう。ダグラス・クロックフォード氏
JSONの発見者でJavScript界の重鎮であるYahoo!のダグラス・クロックフォード（Douglas Crockford）氏。米オライリーが主催するイベント「Velocity 2011」で、セッション「JavaScript & Metaperformance」を行いました。 いまWebブラウザ間でJavaScriptエンジンの性能競争が行われていますが、その影響とこの先の展望について語っています。JavaScriptプログラマなら必見の内容を、公開されたビデオを基に紹介しましょう。 JavaScript & Metaperformance これから、JavaScriptと性能についての本当の話をしよう。 JavaScriptはみなさんご存じかな？ いまや世界で最もポピュラーになったプログラミング言語だ。 JavaScriptは、Javaからシンタックスを、Schemeからファーストク
避けなければいけない JavaScript の失敗 - フリーフォーム フリークアウト
移転しました http://please-sleep.cou929.nu/20110515.html
uupaaさんのCoffeeScript利用時の注意点
えんじに🐈にゃーん🍓🫐🍅🌽🍈🍇🦝 @uupaa CoffeeScriptやる人に一言。jsはシングルスレッドだけど匿名関数でラップすると関数の出口でスレッドコンテキストする可能性あるから、並列処理にスレッドもってかれないように気をつけて。最近某アレで「朝までにページ表示が不安定なのを直して」と泣き付かれた奴はまさにそれだったよ 2011-05-06 01:12:53 えんじに🐈にゃーん🍓🫐🍅🌽🍈🍇🦝 @uupaa CoffeeScriptはうっかり匿名関数でラップするから、「タイミングに依存する作りで、状態遷移をしっかりせず、手抜きしてると先にxhrが終わってしまい、そこで処理もってかれて、準備できてないのにページ表示処理が走って、全体が不安定になる」って奴だった 2011-05-06 01:15:23
AppEngine/Jのspin-upを劇的に改善する方法 - ひがやすを技術ブログ
AppEngineは、アクセスがあったときにアプリケーションを起動し、しばらくアクセスが無ければアプリケーションを終了させ、また次のリクエストで再起動するという仕組みを導入しています。 そのため、アプリケーションを起動(spin-up)する時間がとても重要になってきます。このspin-upの時間はpython(webapp)で60cpu_ms以下。(cpu_msはcpuが使う仮想的な時間ですがmsと同じ感じで捉えてもらってもとりあえずは大丈夫です)JavaのServletだと600cpu_msくらいです。PythonでもDjangoような大きなフレームワークだと1000cpu_msくらい(アプリによる)かかりますが、許容範囲内。JavaだとSlim3で1300cpu_ms、Springだと早くて7000cpu_msという感じで、Slim3がギリギリ許容範囲内でしょうか。ほんとうは、1000
blog.8-p.info: Facebook の BigPipe と TTI
Posted at 2010/10/22 01:59, Modified at 2010/10/22 03:42 Facebook のフロントエンドは結構かわったことをやっていて、例えば、ログイン後の http://www.facebook.com/home.php には <div id="pagelet_home_stream"></div> みたいな空の HTML があり、その後に <script>big_pipe.onPageletArrive({ … });</script> <script>big_pipe.onPageletArrive({ … });</script> ... と script 要素が何個もならんでいる。 BigPipe: Pipelining web pages for high performance この仕組みは (変数名のとおり) BigPipe と呼
JavaScriptをGPUで高速化する試み、モジラがJetpackで検討中 － Publickey
モジラが、JavaScriptをGPUのパワーを借りて高速化する試みを行っています。FirefoxのJetpackプロジェクトに協力しているメンバーがブログにポストしたエントリ「Elevating JavaScript Performance Through GPU Power」で、その可能性と方法について触れています。また1つ、JavaScriptの可能性が広がるかもしれません。 Mozilla Labs » jetpack » Blog Archive » Elevating JavaScript Performance Through GPU Power Webでは高精細な動画や音声などがやり取りされるようになり、またセカンドライフのような3次元表示など、Webブラウザ上で行われる情報処理は高度化しています。 今後はさらに動画の加工や音声認識のような高度なアプリケーション、あるいはW
サイボウズで学んだこと - IT戦記
はじめに 2010 年 9 月 15 日を持ちまして、サイボウズ・ラボを退職いたしたました。 報告も兼ねて、久しぶりにブログを書いてみたいと思います。 （写真はゆうすけべーさんです） この会社に入って、たくさんの学びと思い出がありました。 その一つ一つをまとめていければ、素晴らしい記事になるのかもしれませんが、僕は文章が苦手です。 ですので、うまく退職のエントリを書き上げることができません。 言葉にできない。そんな感じです。 なので、このエントリはサイボウズ・ラボやサイボウズ本社の仲間たちへのありがとうの気持ちをこめて、自分らしく最後まで JavaScript のことを書きたいと思います。 サイボウズでの最後の仕事 僕にとって、サイボウズでの最後の仕事は「JavaScript で新しいユーザーインタフェースを作ること」でした。 そして、その中で始めて複数人による大規模な JavaScrip
HTML5入門：アニメーションの実装方法３種
HTML5・CSS3のような新しい技術の問題点は、HTML4やらFlashなどの枯れた技術と違ってノウハウ・ライブラリ・ツールとかがまだ十分にそろっていない事。普及のタイミングもまだはっきりとしていないこの段階で手を出せない・出しにくいと感じている人が多いのも良く理解できる。 私から見れば、逆に「こんな楽しい状況は滅多にない」わけで、商売になるかならないかは二の次にしていろいろと試したくなる。 今日作ったのは、HTML5+CSS3上で可能になる（ただし現在ではWebkit独自の拡張を含む）３つのアニメーション・テクニックの比較（左に貼付けたものがそれ、Safari/Chromiumだとすべて動く。Firefox/OperaだとDOMとCanvasのみ（ただし別ウィンドウで開かないとCanvasが動かないークロス・ドメインセキュリティのバグか？））。 詳しくはソース（参照）を見ていただければ
+new Date を Date.now() に差し替えると200〜400% 高速化も - latest log
CSS を利用したアニメーションでは、必ず現在時刻を取得するコードが入ります。 var now = +new Date; ECMAScript-262 5th では Date.now() が新しく追加されました。 Date.now() は +new Date と同じ機能(現在時刻を数値で返す)を持ちながら、new の必要がないため速そうです。 ベンチ <!doctype html><html><head><title></title> </head><body> <script> window.onload = function() { Date.now || (Date.now = function() { // Date.now が実装されていないブラウザ用の実装 return +new Date; }); job1(); job2(); } function job1() { var
過去最速のFirefox、しかしアピールすべきは総合力 - Mozilla Flux
Firefox 3.5 Beta 4のリリースを控え、再びそのパフォーマンスを検証する時期がやってきた。これまではJavaScriptの性能だけを見てきたが、今回からはロードタイムの計測なども含める。 使用するのは、Shiretoko Nightly（3.5b5pre, ID:20090424045037）である。バージョン番号は3.5b5preとなっているが、コードベースはFirefox 3.5 Beta 4と実質的に同じだ。なお、「3.5b5pre」の名称は暫定的なものにすぎないので、これをもってBeta 5がリリースされる可能性を云々することはできない。 比較対象として、これまで当ブログで紹介したShiretoko Nightlyの過去のバージョンのほか、Google Chrome（2.0.174.0, AppleWebKit/530.6）とSafari 4.0 Public Bet
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
