Webpack チャンク最適 テクニック - Qiita
ターゲット 巨大なSPAを作ってしまった人へ 巨大なSPAを作らないように気をつけたい人へ 今回はJSだけにフォーカスするが、もっというと、 超速本 を読んでください。 注意：本資料は、webpack チャンクの挙動を概念的に説明することを重視しているので、 webpack の詳細な設定や、出力ファイル名などは実際の処理と一致しない。適宜自分の手元にある設定とすり合わせるように。 昨今のJSビルド問題と、その解決のためのゴール設定 巨大なJS(+最近は in JS された各種SVGやCSS)はダウンロードだけではなく、UIスレッドのCPUをブロックする。 これはとくにCPUが貧弱な端末で体験が悪化する。そしてビルド時間で開発者体験を阻害する。 できれば webpack 推奨の 144kb 以内にしたい…が現実的に難しいので、 せめて 350kb ぐらいに抑えたい。 SPAなら (ローディン
Tumblrの省メモリーな無限スクロール - 記録
無限スクロールまたはauto pagingと呼ばれるUIには、読み終えたコンテンツがどんどん画面の上のほうに溜まっていってメモリーを食い潰すという問題がある。 なかでもTumblrは画像などのコンテンツが多いため、ダッシュボードダイバーたちは無限Tumblrユーザースクリプトなどのユーザースクリプトをインストールして、読み終えたコンテンツを定期的にページ上から自動削除するといった対策を講じていた。 ところが最近のTumblrのダッシュボードでは、ポストが画面外に出るとその中の要素が一時的にページから削除され、画面内に表示されると要素が再度復元されるようになっている。どうやらこれによって無限スクロールによるメモリーの圧迫が抑えられているらしい。 関連するコードはhttps://secure.assets.tumblr.com/assets/scripts/dashboard.jsの/*! s
60fpsのサイトパフォーマンスを目指す - ワザノバ | wazanova
http://calendar.perfplanet.com/2013/the-runtime-performance-checklist/1 comment | 0 pointsGoogle ChromeチームのPaul Lewisが、ページ読み込み後、つまりユーザが閲覧する際の、UIレスポンス、スクロール、アニメーションなどサイトパフォーマンスについてまとめています。 まずは60fpsのパフォーマンスを達成する。よって、16ms以上かかるフレームは全て問題とみなす。 1. Large invalidations of layout and styles エレメントでのクラスの変更やJavaScript/CSS transition/CSS animationで直接エレメントのスタイルを変更すると、ブラウザはレンダリングツリーの一部もしくは全部を無効にしてしまう。最悪のケースでは、ドキュ
Effectively managing memory at Gmail scale | Articles | web.dev
Introduction While JavaScript employs garbage collection for automatic memory management, it is not a substitute for effective memory management in applications. JavaScript applications suffer from the same memory related problems that native applications do, such as memory leaks and bloat, yet they must also deal with garbage collection pauses. Large-scale applications like Gmail encounter the sa
HTML5 Conference 2013 レンダリングパフォーマンスお話してきた！
HTML5 Conference 2013 で、僭越ながら1セッション担当させていただきました！やっっったら、奥行きの深い部屋で、後ろのほうの方にはスライド見えづらかったかもしれません。ごめんなさい。部屋の奥行きのわりに、スクリーン小さいという不遇がありました orz ということで、スライドのURL共有とか、イベントの感想とかです。 Rendering Performance 動画 Webフロントエンドのパフォーマンスは、今やページの初期表示を早くすることだけではありません。昨今のHTML/CSS/JavaScriptを駆使したWebコンテンツを、スムーズに動かすには、ブラウザのレンダリング(描画)処理について知る必要があります。このセッションでは、レンダリング上のよくあるボトルネックの見つけ方と対処を中心に、最適化Tipsをお届けします。 ちと粗いのですが、今回の参考URLリストです。
JSでi++と++iどっちが速い？ - Islands in the byte stream (legacy)
結論から言うと、現在のChromeのみをターゲットにして最適化するという特殊なケースを除き*1、どちらでも変わらないといえます。 [追記] 指摘を受けて再考してみました。そもそもjsperfでは初期化コード（今回はdataなどの初期化に使用）は一度しか走らないにもかかわらず、このベンチマークコードではdataの中身を書き換えています。これがスコアに影響を与えていたようです。 data[index] = data[index] * 2をdata[index] = index * c にした結果はChromeでも安定して双方有意差なしという結果になりました。 http://jsperf.com/postfix-or-pretfix-increment/4 JSのベンチマークの難しさを思い知りました。 [/追記] http://jsperf.com/prefix-or-postfix-incre
JSLitmusを使ってJSのパフォーマンス測定をする - Qiita
// グローバル変数とローカル変数に対するアクセス速度の違いを測定する var global_var = 1; JSLitmus.test('global', function(count) { while (count--) { global_var++; } }); JSLitmus.test('local', function(count) { var local_var = 1; while (count--) { local_var++; } }); ここで第二引数に渡された関数の実行時に count というのが渡されてそれを while (count--) { … } としているが、これは JavaScript の関数呼び出しのコストを抑えるために行う作法のようなものなので基本的にこのフォーマットに従うのがよい。 実行してみる 先ほど作ったhtmlをブラウザで読み込む。すると以
メモリーリークパターンを理解する - babu_babu_babooのゴミ箱
メモリーリークに関する覚え書き メモリーリークとは コンピュータの動作中に、使用可能なメモリ容量が、だんだん減っていく現象。 OSやアプリケーションソフトが、処理のために占有したメモリ領域を、解放しないまま放置してしまうために起きる。 メモリーリークパターン（以下のタイプを考察） ドキュメントツリーに属さないノードに、イベントを貼り付けた場合。 DOM プロセッサが管理しているオブジェクトと、スクリプトエンジンが管理しているオブジェクト、が混在した場合 いわゆるクロージャが、その混在を招くパターン（これが難解） メモリーリークに該当しないもの DOM プロセッサが管理している変数が、グローバル変数である window, document は、グローバル変数なので、該当しない。 ドキュメントツリーに属さないノードに、イベントを貼り付けた場合 ページを破棄するときに、ドキュメントツリーのノード
PNG vs SVG for sprites
About HTML Preprocessors HTML preprocessors can make writing HTML more powerful or convenient. For instance, Markdown is designed to be easier to write and read for text documents and you could write a loop in Pug. Learn more · Versions Adding Classes In CodePen, whatever you write in the HTML editor is what goes within the <body> tags in a basic HTML5 template. So you don't have access to higher-
LazyLoadを実現する1KBを切るjQueryプラグイン「Unveil」:phpspot開発日誌
jQuery Unveil - A very lightweight plugin to lazy load images LazyLoadを実現する1KBを切るjQueryプラグイン「Unveil」 LazyLoadプラグインの余分な機能（エフェクト、イベント）を省いて軽量化したものです。 LazyLoadでページ表示速度をあげようとしてLazyLoadで遅くならないようにしたい場合に使えそう とにかく軽くしたい場合に検討してみてもよいプラグインですね 関連エントリ １ページ内で複数ページに分割できるjQueryプラグイン「windows」 レスポンシブに使えるタブUI実装jQueryプラグイン「Easy-Responsive-Tabs-to-Accordion」 範囲指定が可能になるUI実装jQueryプラグイン「noUiSlider」 レスポンシブに加えスマホ用のメニュー実装もできる
uupaa looper 見っけたよー - latest log
(ε・◇・)з hasOwnProperty を使った for in ループより 20%～84% 低コストな、うーぱー式 ループのご紹介だよ～ Object.keys を使い、key を列挙することで、hasOwnProperty を使った for in ループよりも速くなります。 var keys = Object.keys(obj), i = 0, iz = keys.length; for (; i < iz; ++i) { var key = keys[i]; var value = obj[key]; ... ベンチマーク http://jsperf.com/perf-for-in-loop-vs-pre-enum-keys-for-loop/8 Browser for_in_hasOwnProperty loop uupaa-looper Chrome 16.0.912.77
NAVERまとめに見る遅延ロードのすすめ « NAVER Engineers' Blog
あけましておめでとうございます。NAVERまとめのフロントエンドを担当している縣です。初詣で引いた大吉のおみくじを握りしめながら今年も張り切っていこうと思います。 今回はJavaScriptの遅延ロードの仕組みをNAVERまとめに導入した際のお話を紹介します。 遅延ロードの検討 昨年NAVERまとめのまとめ閲覧ページや、まとめ編集ページでのJavaScriptファイルの読み込みを遅延ロード化する作業をしました。元々はページ読み込み時に全て読み込ませていましたが、JavaScriptファイルが巨大になってきてパース・実行に時間がかかるようになったことから遅延ロードを検討することになりました。 遅延ロードの利点というとJavaScriptファイルの読み込み・実行によるブラウザのレンダリング停止を防ぐのはもちろんですが、どのファイルがいつどこで必要になるかを明確にすることもでき、依存関係を動的
HTML5開発者必見、最速のJavaScriptライブラリはどれだ!? パフォーマンスの徹底検証 | ICS MEDIA
HTML5で2次元のインタラクティブコンテンツを制作するには、さまざまなJavaScriptライブラリがあります。どれを選択するべきか迷いどころではないでしょうか？ そこで今回はHTML5の各種JavaScriptライブラリについて、パフォーマンスを比較検証してみました。 今回検証したフレームワーク メジャーなJavaScirptライブラリとして次の5種類でテストしました。バージョンは2013年4月10日現在の最新版を使っています。詳しい検証方法は記事の後半にまとめています。 CreateJS (EaselJS 0.6.0) Arctic.js (v0.1.11) enchant.js (v0.6.3-48) Pixi.js (v1.0.0) Processing.js (v1.4.1) 各種JavaScirptライブラリのベンチマーク結果 ※グラフの数値が高いほどパフォーマンスが高いこと
dresscording.com
dresscording.com 2019 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
Webアプリケーションを高速化する50のトリック
MicrosoftのInternet Explorer PMであるJatinder Mann氏は、BUILD 2012でHTML5アプリとサイトを高速化する50のパフォーマンストリックというセッションで、Webアプリケーションを高速化する多くのチップスを提供した。 Mann氏が提供したアドバイスは、以下の6つの原則を中心に構成されていた。 1. ネットワークリクエストに迅速に応答する リダイレクトを避ける。上位1,000のWebサイトのうち63%は、リダイレクトを使用している。これらはリダイレクトをやめることによって10%のパフォーマンスを改善することができる。 メタリフレッシュを避ける。世界のURLのうち14%は、メタリフレッシュを使っている。 可能な限りユーザーの近くにあるCDNを使用してサーバーの応答時間を最小化する。 異なるドメインからのリソースをダウンロードすることによって、同時
WebWorkerでXMLHttpRequest - Qiita
XMLHttpRequestをWebWorkerで実行する Senchaが公開したHTML5のFacebookクライアント、Fastbookの高速化手法として、 XMLHttpRequestをWebWorkerで実行するのがあるそうです。 ということで、実際にやってみました。 WebWorkerの呼び出し jQueryを用いた環境で使いやすいように、jQueryの$.ajaxインターフェイスに似せています。 ただし、XMLHttpRequestをWebWorkerからは取得できないので、全く一緒ではありません。 ExecutorServiceの実装 WebWorkerを大量に作成すると負荷がかかるので、 少し手間ですが、同時実行数を制限し、リクエストをキューイングする ExecutorServiceを実装します。 var ExecutorServece = (function() { Ex
CoffeeScript's for vs. Underscore _.each vs. jQuery $.each · jsPerf
CoffeeScript's for vs. Underscore _.each vs. jQuery $.each JavaScript performance comparison Revision 3 of this test case created by Onigoetz on 2012-4-10 Preparation code <script src="https://raw.github.com/documentcloud/underscore/ba3e31b53ef5752b40cfb2d71f594536fefbe916/underscore-min.js"> </script> <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"> </script> <scrip
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Effective web performance tuning for smartphone
Lodash foreach · jsPerf
HTML5フレームワークにおける表示オブジェクトのパフォーマンス検証
