Webフロントエンドパフォーマンスチューニング85選 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは、ぬこすけです。 近年、Webフロントエンドではサイトのパフォーマンスの重要性が高まっています。 例えば、GoogleはCore Web Vitalというパフォーマンスに指標を検索結果のランキング要因に組み込みました。 また、近年の某企業が「パフォーマンスの改善に取り組んだ結果、セッション数〇％アップ、CVR〇％アップ...」などの事例は枚挙にいとまがないでしょう。 パフォーマンスチューニングするためには、定量的に計測してボトルネックを探すようなトップダウンなアプローチもあります。 しかしながら、時には千本ノック的にハウツーを
実践 Off the main thread - from scratch
実践 Off the main thread 実際に Off the main thread をやりつつ、パフォーマンスチューニングをする際にどこに気をつけるべきかを今やっているので、それについて話します。 Off the main thread とは JavaScript の処理は基本的にメインスレッドで実施します。JavaScriptの実行処理以外にも記述された内容を解釈するためのパース処理やGC処理もメインスレッドをブロックします。メインスレッドの処理が多いとUI jankと呼ばれるガタツキ、チラツキ、画面の固まりの原因になります。 UI jankが発生していると、ユーザーがクリックしたり、text入力をしようとしてから反応するまでの時間（Input Latency）が即時ではなくなります。 このUI jankを無くすために、なるべくメインスレッドを阻害する要因を減らすことが Off
フロントエンドコーディングにおけるPageSpeed Insights対策 / frontend pagespeed insights-
フロントエンドコーディングにおけるPageSpeed Insights対策 / frontend pagespeed insights-
The Cost Of JavaScript - Addy Osmani - Fluent 2018
As the world build sites that are more heavily reliant on JavaScript, we sometimes pay for what we send down in ways that we can’t always easily see. Addy Osmani explains how and why JavaScript is the most expensive resource your site uses today—especially on mobile. Addy also shares tips for fixing JavaScript performance issues so everything loads quicker. A little discipline can help if you wan
dev.toコードリーディング会に参加した - mmag
smarthr.connpass.com 行ってきました。十数人で各々が好きなところから読み始めて、最後に見所や気づきを喋る流れでした。initializersを読んでいく人やモデル中心に見ていく人など様々。近日中に全員のメモが公開されるとのことですので、そのときはリンク追記します。会場を提供してくださったSmartHRさんありがとうございました。 追記 先週金曜の dev\.to コードリーディング会に参加した皆さんのメモはこちらに公開されてますhttps://t.co/uipqG1pYxu— ぷりんたい (@spacepro_be) 2018年8月13日 追記ここまで 以下は自分のメモ。やはりdev.toと言えば爆速なので、CSSをheadタグに埋め込んでいたり、キャッシュってどうやってんだろうなーといったところを中心に読みました。最後の所感にも書きましたが、爆速サイトをつくるためのイ
JavaScript Start-up Performance – Dev Channel – Medium
Update: The Cost Of JavaScript In 2019 is now available to read. As web developers, we know how easy it is to end up with web page bloat. But loading a webpage is much more than shipping bytes down the wire. Once the browser has downloaded our page’s scripts it then has to parse, interpret & run them. In this post, we’ll dive into this phase for JavaScript, why it might be slowing down your app’s
JavaScript Start-up Optimization | Articles | web.dev
As we build sites more heavily reliant on JavaScript, we sometimes pay for what we send down in ways that we can’t always easily see. In this article, we’ll cover why a little discipline can help if you’d like your site to load and be interactive quickly on mobile devices. Delivering less JavaScript can mean less time in network transmission, less spent decompressing code and less time parsing and
ページ上でずっと動いているsetTimeout、setInterval、requestAnimationFrameを見つけてパフォーマンス改善する
ページ上でずっと動いているsetTimeout、setInterval、requestAnimationFrameを見つけてパフォーマンス改善する 複雑なウェブアプリケーションになってくると、1つのページで複数のTimerなどを回すことがあります。 例えば、Twitterのようなアプリならば、ポーリングで更新するためにsetInvervalのようなタイマーを回します。 また、ゲームなどCanvasで描画を行うアプリケーションならば、メインループをrequestAnimationFrameで回します。 このように色々なタイマー系がありますが、アプリが多機能になっていくと色々なタイマーが同時に動くようになっていきます。 特に問題がなりやすいのが表示中だけタイマーを回すコンポーネントです。 よくあるのが次のようなmount時にtimerを開始して、unmount時にtimerを停止するコンポーネ
Node.js Performance 改善ガイド - from scratch
Node.js Performance 改善ガイド Memory の場合 メモリリークかどうかを特定する メモリリークではない場合 CPU の場合 どこの処理に時間がかかっているのかを確認する v8 simple profiler flame graph を取得する File の場合 大きなサイズのファイルをどうしても扱う時 Network の場合 keepalive を on にする その他: 全体的にパフォーマンスを改善するためにやること JIT が効いているかを確認する clusterが使えないか検討する C++ addons vs JavaScript libraries まとめ 参考資料 Node.js Performance 改善ガイド この記事は Node.js 2 Advent Calender の 5日目の記事です。 qiita.com Node.js のパフォーマンスに
The Cost Of JavaScript
As we build sites more heavily reliant on JavaScript, we sometimes pay for what we send down in ways that we can’t always easily see. In this post, I’ll cover why a little discipline can help if you’d like your site to load & be interactive quickly on mobile devices. tl;dr: less code = less parse/compile + less transfer + less to decompress NetworkWhen most developers think about the cost of JavaS
続・ハイパフォーマンスwebサイト読んだまとめ - Qiita
以前の記事で参考文献に上げたオライリーの「続・ハイパフォーマンスWebサイト」をちゃんと読んでいないことに気がついたので、GW に読み、その内容と感想をまとめてみました。 本書が発行されたのが2010年、HTML5 や CSS3 は草案が発表され、 それらの対応ブラウザも限られている状態でした。（国産Android が発売されたのもこの年） ES2015 など影もない時期で今から見ると古い内容もありますが、普段なんとなく避けていたことの理由が述べられていたりと勉強になりました。 しかし、最初の「ハイパフォーマンスWebサイト」のほうがインパクトが大きく、 すぐに取り組むべき内容がまとめられているので 未読の方はそちらを優先にすると良いと思います。 また web パフォーマンスに関する書籍として、最近 Webフロントエンド ハイパフォーマンス チューニング という本も出版されました。 こちら
The Benefits of Server Side Rendering Over Client Side Rendering
Most of our pages on walmart.com are using server side rendering (henceforth SSR) with only a few unique exceptions. We are using server side rendering for two reasons: Performance benefit for our customersConsistent SEO performanceDue to the benefits of SSR, when we transformed our stack to React and Nodejs, we put a lot of time and effort in optimizing SSR performance. One of our key metrics for
A Comprehensive Guide To HTTP/2 Server Push — Smashing Magazine
In this article, Jeremy Wagner will teach you everything about server push, from how it works to the problems it solves. Server push allows you to send site assets to the user before they’ve even asked for them. It’s an elegant way to achieve the performance benefits of HTTP/1 optimization practices such as inlining, but without the drawbacks that come with that practice. Jeremy will also show you
アメブロ2016 ~ React/ReduxでつくるIsomorphic web app ~ | CyberAgent Developers Blog | サイバーエージェント デベロッパーズブログ
みなさんこんにちは、サイバーエージェントでフロントエンドを中心に開発しています原(@herablog)です。 アメブロでは、2016年9月にフロントエンドをJavaベースのアプリから、node.js・Reactベースのアプリへとシステムの移行をおこないました。本記事では、その移行へといたる経緯やゴール、システム設計、その結果についてお伝えします。 リリース直後に気づいているツワモノな方もいらっしゃいました。 アメブロのSP版がReactのSSRでフルリニューアルしたのを観測した — hr (@hrloca) 2016年9月1日 システム移行へといたる経緯 2004年から始まり、日本国内で最大規模のブログサービスとなったアメブロは、システムの肥大化や多数の関係者が存在したことによるモジュール・導線の急増などの理由により、ページ表示スピードが遅くなり、ページビュー数にも明らかに影響を与えるよう
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
Real-world JavaScript Performance
このブラウザ バージョンのサポートは終了しました。サポートされているブラウザにアップグレードしてください。
フロントエンド速度改善でやったこと(Expiresヘッダ、faviconのgzip圧縮、JSの読み込み遅延化) - $shibayu36->blog;
フロントエンド速度改善をしようとして参考にしたもの - $shibayu36->blog; という記事を以前に書いたのだけど、結局何をやったか書いて欲しいと社内で言われたので、今回のフロントエンドの速度改善でやったことについて書いてみる。そこまで大したことはやってないので参考程度にどうぞ。 前提 ページのレンダリングが遅いと思い始めたので改善をすることになったのだが、改善をし始めたところChromeのアップデートがあり爆速になってしまった(FirefoxやSafari等はもともと速かった)ので、では明らかにやったほうが良いことだけやりますかという話になった。そのためあんまりbefore/afterもちゃんと取っていないので、今回はやったことの紹介くらいに留める。 やったこと 計測や調査をしてみたところ、以下のようなことはやってしまったほうが良いということになった。 静的ファイルに適切にEx
Reactを使ったプロダクトのパフォーマンスを改善した話 | GMOメディア エンジニアブログ
技術推進室の色川です。 ここ一年くらいランキングシェアというキュレーションメディアのフロントエンドを担当しています。その記事作成画面をReactで実装しており、先日アイテムの移動をDrag&Dropで行えるようにしたのですが、動きはガクガク、ブラウザは途中で固まる、という有様で、パフォーマンスチューニングを余儀なくされたのでその内容を紹介します。 ［ランキングシェアの記事作成画面］ ※画面は開発中のものです。（動画にしたら？との意見があったのですが、Windowsで画面を録画する方法が分からず…） Reactのパフォーマンス改善の基本Reactはコンポーネントをツリーとして管理していて、あるコンポーネントの更新が必要になるとそのコンポーネントをルートとするサブツリー全体を更新します。 引用元：Reactive, Component-based UIs with React | Consta
Navigation Timing APIでブラウザの処理時間を可視化するツール作った - ( ꒪⌓꒪) ゆるよろ日記
最近のブラウザでは、 Navigation Timing API ってのがサポートされていて、これを利用すればブラウザがページをロードするのに要した処理時間の内訳を知ることができる。 例えば、"DNSのlookupに要した時間"や"DOMの構築処理時間"、"onloadイベントの処理時間"などを見ることができるので、クライアントサイドのパフォーマンス計測に役立てることができる。 Navigation Timing Navigation Timing APIの仕様 #JavaScript - Qiita HTML5で Speed Test, Navigation Timing APIによる性能データ収集 - ぼちぼち日記 Navigation TimingでWebアプリの読み込み時間ログ取得 - l4l このAPIは、 window.performance.navigationオブジェクトや
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
20160930 フロントエンド高速化 業務編 (社内勉強会)
