Chrome Devtools による フロントエンドパフォーマンスの計測
こんにちは。株式会社スタメンでFANTSのフロントエンドを担当している@0906kokiです。 今回の記事では、皆さんおなじみの Chrome Devtools にある Performance タブで、フロントエンドのパフォーマンスを計測する方法について書きたいと思います。 はじめに フロントエンドのパフォーマンス・チューニングと言うとバックエンドと比べて後回しになりがちですが、フロントエンドにアプリケーションの複雑性が寄ってきている現在、フロントエンドがボトルネックでレスポンスのレイテンシーが発生することは往々にしてあると思います。 バックエンドではユーザー数の増加や大量の同時接続に耐えられる負荷対策やパフォーマンス・チューニングが中心となりますが、フロントエンドではプロジェクトサイズの増加による JavaScript ファイルのダウンロードやスクリプティング、レンダリング速度の低下等が
実践 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
一休.comスマホサイトのパフォーマンス改善（JavaScript編） - 一休.com Developers Blog
宿泊事業本部の宇都宮です。 一休.com スマホサイトのホテルページパフォーマンス改善プロジェクトでは、フロントエンドには以下のような要件がありました。 デザイン面は既存を踏襲する 機能はほぼ従来通り 日付等を変更した際の再検索は、画面遷移を挟まず、画面内で行えるようにする パフォーマンスをできるだけ改善する 要するに、従来と同様の機能+αを実現し、かつ、従来と同等以上のパフォーマンスを実現する、というミッションです。 このために、どのような取り組みを行ったか、紹介します。 パフォーマンス目標値の設定 まず、パフォーマンスの目標値を設定する必要があります。モバイルでは、ユーザの帯域幅は回線や時間帯によって大きな変動があります。多少回線状況が悪くても、閲覧を妨げない程度のパフォーマンスを実現する必要があります。 一休へアクセスするユーザのモニタリングを見ると、極端に遅い回線を使っているユーザ
Webフロントエンド パフォーマンス改善ハンドブックを公開しました - dwango on GitHub
パフォーマンス改善ハンドブック ウェブページにおけるパフォーマンスに関する問題の見つけ方や考え方の事例をまとめた Webフロントエンド パフォーマンス改善ハンドブックを公開しました。 URL: https://dwango-js.github.io/performance-handbook/ このハンドブックでは過去に行ったWebフロントエンドのパフォーマンス改善の事例を中心に紹介しています。 注意点としてWebフロントエンドは常に変化しているため、現在の最適な解決方法を提案するものではありません。 また、アプリケーションによっても最適な解決方法は異なります。 今回の事例ではViewライブラリにReactを用い、映像再生プレイヤーなどある程度複雑な機能を持ったウェブアプリケーションのWebフロントエンドを扱います。 具体的にはニコニコ生放送（以下「生放送」）で行った事例を中心に書かれていま
dev.toがなぜinsanely fastを実現出来ているか - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? INSANELY FAST Qiitaを読んでる人なら https://dev.to をほとんどの人が見たはず。見てない人は見てきてください、速すぎて驚くはず。またmizchiさんがdev.toに書いた なぜ dev.to がこんなにも速く、こんなにも自分にとって感動的なのか - dev.to を見た人も多いと思う。個人的にHeroku, Railsを採用してここまで爆速なサイトを構築出来ていることは今までの常識を覆す衝撃な出来事だった。こんな新しい発見をもたらしてくれたdev.toには本当に感謝してる。自分もこんなサイト作ってみたいな
なぜ dev.to がこんなにも速く、こんなにも自分にとって感動的なのか
最初にいっておく。これは負け惜しみだ。 SPAとPWAの現状 自分は日本でReactの勝手エヴァンジェリストみたいなことをやっていて、SPAの重めのコンテンツをよく作ってるからか、「お前らフロントエンドを物事をややこしくして、重いページを量産してウェブを劣化させてるじゃないか！」みたいな批判を、名指しでよく受ける。なんで僕にいうかわからないけど、React = SPA みたいなイメージでスケープゴートにされてるんだろう。それはまあいい。 自分の仕事でSPA技術を使うところは、ちゃんと必要性もあるし理由も説明できる。ただ、やはり近年の複雑化/重量化について思うところはあるので、逆に振って AMP/PWA という選択肢を持っておきたくて、正直言うと依頼されたR&Dの仕事でもあったんだけど、一通り覚えた。なんだけど、今のところ仕事で使うタイミングがない。 PWA技術を仕事で使えなかった理由として
ウェブフロントエンドのパフォーマンス改善のひとつの日常 - kitak blog
ひとつの日常 この間、仕事でちょっとしたハイブリッドアプリ(ネイティブアプリのWebViewの上で動くWebアプリ、とここでは定義しておく)をリリースした。 そのアプリにはタブがあって、(当たり前だが)タブでコンテンツが切り替わる。 リリースして3日くらい経って、企画の人から「なんか、ここのタブ、反応悪くない？」という話が来た。たしかにタブに触れても、すぐには反応しなくて1~2秒経ってからタブが切り替わる。しかも、切り替えたタブのコンテンツが表示されるのにも1~2秒かかっている、うへー... 改善するぞ！ ということは、クライアントの開発をおこなっていると、ちょくちょくあるのではなかろうか。意識、あるいは無意識におこなっている改善の手順について、先の問題の改善に至るまでの具体的は話、ツールも含めながら書く。 計測する 「計測するまでは速度のための調整をしてはならない」という有名な格言がある
シンプルでかつ最高のJavaScriptプロファイラ sjsp を作りました！ ― Webアプリケーションが複雑化する中でプロファイラに求められるものとは何か - プログラムモグモグ
あらすじ Web技術が複雑になる中で、JavaScriptのプロファイリングをとる方法とは。 プロファイリングを取るためのコードを手で書いてみましょう。 とてもシンプルで、かつ最高のJavaScriptプロファイラ sjsp を作りました。 本当にあった怖い話 上司 「とにかくJavaScriptのコードを速くしてくれ」 私 「分かりました、速くします」 (次の日) 私 「いいプロファイラがないなら作ればいいじゃない」 同じチームの人 「えっ？」 私 「最高のJavaScriptプロファイラ作ったよ」 同じチームの人 「「えっえっ？？？」」 私 「早速使ってみたらこことここが遅いって分かったよ」 同じチームの人 「「「この子は一体…」」」 JavaScriptのプロファイリングの難しさ 近年、Webブラウザーの処理速度は著しく向上し、その可用性の高さから、アプリケーションのプラットフォーム
『フロントチューニンガソン 最速を目指すには』
11:10～ 課題ページの確認＆PageSpeed Insightsの実行目的：チューニング対象のウェブサイトの改善の余地を調査 上記のgruntプラグインをインストールする npm install コマンドを実行しながら、ブラウザやIDEでチューニング対象のウェブサイトを確認し始めました。 少し見ただけでもCSSの構文エラーがあったり、使っていないJavaScriptライブラリがインポートされていたり…。 まるで無茶な運用を数ヶ月続けたかのような、カオスなファイル群でした。 ここで実行した PageSpeed Insights に画像サイズの最適化をオススメされたので、まずはそこから行うことにしました。 11:20～ 画像ファイルの最適化目的：画像ファイルサイズの削減 30 x 30pxで表示している画像ファイルが実際には150 x 150pxで保存されていたりする画像がそこそこあったの
AngularJSのチューニング - ワザノバ | wazanova.jp
http://blog.scalyr.com/2013/10/31/angularjs-1200ms-to-35ms/ モニタリング/ログ分析ツールのScalyrがそのブログで、AngularJSをチューニングしてページの更新時間を短縮した事例を紹介してます。成果は近日中にオープンソースとして提供される予定です。 1) 背景 Scalyr Logsアプリにおいて、DBクエリは数十 msで処理できるが、ページの読み込み時間で数秒かかってしまう状況であった。シングルページアプリを実現するためのフレームワークとしてAngularJSを採用。”fail fast” (失敗するなら早めに)の方針のもと、難易度の高いログビューからつくることにした。 Scalyr Logsのページに表示されたログデータのどの単語をクリックしても、その検索結果を表示。(サンプル画面 / デモ画面）次ページのログデータも事
ScaleOut | Supership
日々の出来事、メンバーの働く様子や声、未来への想いなど、Supershipの“BE SUPER”なストーリーをシェアしています。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
