Webフロントエンドパフォーマンスチューニング85選 - Qiita
こんにちは、ぬこすけです。 近年、Webフロントエンドではサイトのパフォーマンスの重要性が高まっています。 例えば、GoogleはCore Web Vitalというパフォーマンスに指標を検索結果のランキング要因に組み込みました。 また、近年の某企業が「パフォーマンスの改善に取り組んだ結果、セッション数〇％アップ、CVR〇％アップ...」などの事例は枚挙にいとまがないでしょう。 パフォーマンスチューニングするためには、定量的に計測してボトルネックを探すようなトップダウンなアプローチもあります。 しかしながら、時には千本ノック的にハウツーを片っ端から試していくボトムアップなアプローチも有効になることもあったり、日々のコーディングでパフォーマンスを意識したコードを書くことは大切でしょう。 この記事ではパフォーマンス最適化のハウツーを紹介します。 パフォーマンス改善の施策が思い浮かばない時やフロン
yarn installが遅い原因の調査方法
yarn installが遅い原因の調査方法 プロジェクトが依存するパッケージに比例して線形にインストール時間が増えていることが期待します。 投稿日2019-06-13 07:59:00更新日2019-06-13 07:59:00 はじめに npmもしくはyarnのインストール時間が明らかに遅くなっていく場合があります。 早くする方法としては、まずcacheを有効にすることですが効かないパッケージも存在します。 そのようなパッケージをあぶり出すにはどうしたらよいか、というのが今回のお題です。 npm/yarn系の依存するパッケージ数は大抵の場合、人間が把握しきれない量です。 その中から原因をすぐに特定することは困難であるため、人間か理解できる範囲まで情報を絞り込む必要があります。 今回、インストールのログから情報を精査し、ボトルネックとなっている部分を浮き彫りにする方法を紹介します。 ya
2019年版: JavaScriptのループの考察 - Qiita
JavaScript いつの間にかずいぶん違う言語になったなぁ、と思うけど、 for(let i = 0; i < 100; i++) { /.../ } これはまだこう書くしかないのかな？const使えない？ — Takuo Kihira (@tkihira) June 6, 2019 このツイートを起点に、パフォーマンスの話が出て、紀平さんも計測されていたんですが自分でも思うところがあって計測して考察してみました。 実測前の僕の予想（というか過去の経験）は 普通のforが最速 for-inは速度以前に使ってはいけない for-ofとforEachは関数呼び出しがループごとに挟まるのでどちらも遅いが同じ水準 for ofは言語標準なので最適化が行われる期待！ でした。さて、結果はいかに？ それぞれのループの解説 伝統的なfor 伝統的なループが一番軽いというのはみんなが認めるところです。
Maybe you don't need Rust and WASM to speed up your JS
Few weeks ago I noticed a blog post “Oxidizing Source Maps with Rust and WebAssembly” making rounds on Twitter - talking about performance benefits of replacing plain JavaScript in the core of source-map library with a Rust version compiled to WebAssembly. This post piqued my interest, not because I am a huge on either Rust or WASM, but rather because I am always curious about language features an
モノモーフィズム（単相性）について – JavaScriptのパフォーマンスを例に | POSTD
JavaScriptのパフォーマンスに関する講演やブログ記事では、よく単相的コードの重要性が強調されています。しかしながら、モノモーフィズム（単相性）／ポリモーフィズム（多相性）とは何なのか、それがどうパフォーマンスに影響してくるのかということについては、あまり分かりやすく説明されていません。私自身の講演でも、＜＜ 1.良い型、2.悪い型 ＞＞的な二者択一のスタイルに要約してしまうことが少なくありません。パフォーマンスに関するアドバイスを求められることがありますが、そういう時に最もよくリクエストされるのは、 モノモーフィズムとは実際のところ何なのか 、ポリモーフィズムがなぜ生じ、それがなぜ悪いのか、ということを説明して欲しいというものです。 困ったことに、そもそも「ポリモーフィズム」という用語そのものが相当に多重定義されています。昔ながらのオブジェクト指向プログラミングにおいては、 ポリモ
FRESH! Web パフォーマンス改善 〜クライアントサイド編〜 | CyberAgent Developers Blog
You can read this post in English. みなさんこんにちは、FRESH! でフロントエンドの開発している鈴木(sutiwo)です。 前回は、FRESH!におけるPCブラウザのFlash脱却という HLS の Web プレイヤーについて記事を書きました。 今回はスマートフォン・ PC でのブラウザに関するパフォーマンス改善の取り組みとその結果についてお知らせします。 まずクライアントサイドのパフォーマンス改善を行うにあたり、弊社の Web Initiative Center* から 1000ch 氏に加わっていただきどのようなことを目標とするか議論しました。 * Web プロダクトの品質向上とWeb技術を使ったチャレンジを目的に設立された弊社の組織 議論の様子 議論を行った後、今回の改善で以下のことに取り組むことが決まりました。 Service Worker で
Front-End Performance Checklist 2021 (PDF, Apple Pages, MS Word) — Smashing Magazine
Let’s make 2021… fast! An annual front-end performance checklist (available as PDF, Apple Pages, MS Word), with everything you need to know to create fast experiences on the web today, from metrics to tooling and front-end techniques. Updated since 2016. Ah, you can also get useful front-end tips in our email newsletter. This guide has been kindly supported by our friends at LogRocket, a service t
performance.markでパフォーマンス計測する
JavaScriptである区間にかかった時間を計測する時に、次のようなコードを書いたことがあると思います。 const start = performance.now(); // 処理 // 色々な処理がすべて終わった doSome(() => { console.log(performance.now() - start); }) Performance Timelineのperformance.markとperformance.measureなどを使うと、ある区間の処理時間をもっと簡単に取ることができます。 APIについて詳しくは以下の記事を見るといいと思います。 User Timing API: あなたの Web アプリをもっと理解するために - HTML5 Rocks Performance.mark() - Web API インターフェイス | MDN 簡単に解説すると perf
するするさせたい：サイボウズ採用情報のアニメーション（その1） - fragmentary
サイボウズの採用情報ページを見ていた。 サイボウズ | 採用情報（新卒・キャリア） といっても受けるとかではなく、ただ性格悪いことを思っていただけなんだけど。 Kintoneのセクションでアプリっぽいアイコンたちが右から左へと流れているんだけど、それがガタガタとしている。するするしていない。するするさせたい。 というわけで、何が起こっているのかを調べてみようかと。何回かにわけて書くよ。 その1 ― 何が起こっているのか調べる その2 ― 調べながら直しながらするするさせる その3 ― ちょっとしたことや他のブラウザでもするするさせる アニメーションの実装を調べる あとのことを考えて、Chrome DevToolsを使う。 まず、該当の流れるアイコンのところで右クリックしてinspectする。Elementsパネルで、<div class="icon"> という要素がハイライトされる。div
BabelとTraceurでES6末尾再帰最適化を試す - teppeis blog
ちょっと前にBabelに末尾再帰最適化が入って話題になったけど、同じくTraceurにもv0.0.85で最適化が入ったので試してみた。 末尾再帰最適化って何？ 厳密な話はそちらの筋に任せるとして、ざっくりしたストーリーはこんな感じ。 再帰って深くなるとstack overflowになっちゃう 再帰をシンプルなループ（スタックを使わないジャンプ）に変換できればstack overflowを避けられる 一般に末尾再帰であれば再帰をループに変換できる方法が知られている（これが末尾再帰最適化） 末尾再帰とは、関数の最後のステップだけで再帰呼び出しを行うこと 末尾再帰ではない再帰関数でも、CPS変換を使うことで末尾再帰関数に変換が可能 CPS変換とは、関数を結果の値を受け渡すスタイルから継続渡しスタイルに書き換えること つまり、普通の再帰関数 -> CPS変換で末尾再帰化 -> 末尾再帰最適化を適用
VirtualDOM のパフォーマンステストについて，その後 - webとかmacとかやってみようか R
はじめに 年末に書いたエントリーについて、あちこちで言及がありました*1。 師走の忙しさにかまけて勢いで書いてしまったところも多いので、少し補足をしたいと思います。 Virtual DOMってどんだけ早いの？測ってみた - webとかmacとかやってみようか R まず、最初に断っておきますが、これは Virtual DOM のパフォーマンスを厳密に測定したものではありません。元ネタはこちらです。Blazing-Fast-Html（翻訳: 【翻訳】爆速HTML – Elmでの仮想DOM） AltJS の一つである elm という Haskellっぽく FRP を実現できる関数型言語があります。それを作っている Evan Czaplicki 氏のBlog記事です。彼が作った TodoMVC のパフォーマンス比較が github に公開されているので、それを各ライブラリを最新版にして紹介したのが
シンプルでかつ最高のJavaScriptプロファイラ sjsp を作りました！ ― Webアプリケーションが複雑化する中でプロファイラに求められるものとは何か - プログラムモグモグ
あらすじ Web技術が複雑になる中で、JavaScriptのプロファイリングをとる方法とは。 プロファイリングを取るためのコードを手で書いてみましょう。 とてもシンプルで、かつ最高のJavaScriptプロファイラ sjsp を作りました。 本当にあった怖い話 上司 「とにかくJavaScriptのコードを速くしてくれ」 私 「分かりました、速くします」 (次の日) 私 「いいプロファイラがないなら作ればいいじゃない」 同じチームの人 「えっ？」 私 「最高のJavaScriptプロファイラ作ったよ」 同じチームの人 「「えっえっ？？？」」 私 「早速使ってみたらこことここが遅いって分かったよ」 同じチームの人 「「「この子は一体…」」」 JavaScriptのプロファイリングの難しさ 近年、Webブラウザーの処理速度は著しく向上し、その可用性の高さから、アプリケーションのプラットフォーム
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - davidmarkclements/flatstr: Flattens the underlying C structures of a concatenated JavaScript string
20160930 フロントエンド高速化 業務編 (社内勉強会)
Virtual DOM Benchmark
ケーススタディで考えるウェブフロントエンドパフォーマンスチューニング - YAPC::Asia Tokyo 2014
Matt-Esch/mercury-perf · GitHub
TodoMVC Benchmark
evancz/todomvc-perf-comparison · GitHub
TodoMVC Benchmark