Webpagetestから始める継続的パフォーマンス改善
autoscale: true Webpagetestから始める継続的 パフォーマンス改善 ページロードタイム編 :hourglass: 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info Create: textlint, Almin アジェンダ パフォーマンス改善は指標を決めて行わないと迷子になる パフォーマンス改善を行うには継続的な計測を行う 今回はページロードについて、ランタイムは範囲外 パフォーマンス改善のアプローチ 継続的なパフォーマンス計測とリグレッションの検知 ^ 目的はパフォーマンス改善には計測が必要という事実を知ること ^ パフォーマンス計測は継続的に行う必要がある ^ パフォーマンス改善は何を目的、指標にして改善するかを決めないと迷子になる ^ 目的をもって継続的にパフォーマンス改善を行い
Lighthouseでwebサイトのパフォーマンスを計測する - Qiita
こんにちは、スープです。 Prottというプロトタイピングツールのフロントエンドディベロッパーです。 この記事ではGoogleが開発しているLighthouseというツールを紹介します。 Lighthouseとは webサイトのパフォーマンスやアクセシビリティ、WPA等のメトリクス測定ができるツールです。 GithubのREADMEにはこうありました。 Lighthouse analyzes web apps and web pages, collecting modern performance metrics and insights on developer best practices. Github：https://github.com/GoogleChrome/lighthouse 公式ページ：https://developers.google.com/web/tools/li
Making dev.to insanely fast
It makes me smile when someone raves about how fast this website loads, because that's no accident. We put a lot of effort into making it so. It is the sort of thing that usually goes unnoticed, but when your readers are developers, there's a better chance they notice and appreciate it. I have written about this in the past, but it's worth re-examining because these ideas are always evolving. From
Web クライアントサイドのパフォーマンスメトリクス — Speed Index、Paint Timing、TTI etc...
色々なパフォーマンス指標のこと 何かを評価するときには何らかの指標（メトリクス）を定めますが、何を指標として設定してどのように測るかというのは重要です。 いわゆる KPI もそうですが、扱っている商材やビジネスのステージ（フェーズ）によっても適切な指標は変わるかもしれません。色々な指標をよく理解して引き出しを広げておくことは、状況に合わせて適切な指標を選んで改善していく過程で役立ちます。 これまでのパフォーマンス指標 過去の Web パフォーマンス界隈はバックエンドから HTML ドキュメントを返却する際の所要時間や、Web ページロード時の各イベントの発火時間を計測する方法が多く見られました。 Backend Time Browser Event Based DOMContentLoaded Page load ( onload ) 近年は特に後者の、既定のイベント発火に依存していたクラ
AbemaTVのランタイムパフォーマンスのAudit - 1000ch.net
2016.05.17AbemaTVのランタイムパフォーマンスのAudit最近業務で、巷で話題のAbemaTVのパフォーマンス改善をしている。個別具体性が高いが調査改善の雰囲気を感じ取ってもらえればそれで良いかと思い、記事にした。 AbemaTVのフロントエンドの構成話の前提となるAbemaTVのフロントエンドの構成は次の通りで、まさに流行りのといった感じ。 facebook/reactfacebook/immutable-jsReactive-Extensions/RxJSreactjs/react-routercss-modules/css-modulesビルド周りはbabelとwebpack、あとはlintツールがちょこちょこ入ったりしている。この改善の話と関係してくるのは、ReactとImmutableJSとRxJSだけ。 番組再生画面のコメント開閉が重い今回ケーススタディとして挙げ
@tagomorisさんによるISUCON5裏話 - たけぞう瀕死ブログ
先週の社内勉強会では@tagomorisさんにお越しいただき、ISUCON5で使われたベンチマークツールについてお話しいただきました。 資料も公開していただいています。 Tale of ISUCON and Its Bench Tools from SATOSHI TAGOMORI www.slideshare.net ISUCONで使われるベンチマークツールは アプリケーション以上に負荷をかけきるための性能 アプリケーションの処理結果を検証するための機能 という相反する2つの要件を同居させる必要があるため、既存のベンチマークツールやテストツールを利用できないため毎回スクラッチで開発されているそうです。 今回はhttp_loadを使おうと思っていたけど、一週間前にhttp_loadではセッションが扱えないことに気づいてJavaでjetty-clientやJackson、Jsoupなどを使っ
talk 17 - Quantify and improve real-world RAIL
Quantify and improve real-world RAIL Ilya Grigorik You’ve mastered DevTools and tuned your application to follow all the RAIL best practices. Except, how it does perform on your users devices in the real world? We’ll take a look at existing, new, and upcoming APIs that will help you quantify and ...
A Primer for Web Performance Timing APIs
High-Resolution Time Introduction All of the metrics that participate in the Performance Timeline are able to provides timing data in sub-millisecond resolution, i.e. in DOMHighResTimeStamp, which is defined by the High Resolution Time specification [[HR-TIME-2]]. Monotonic Clock In early stages of design, our Timing APIs were defined in terms of wall-clock epoch times. Unfortunately, such times o
A Primer for Web Performance Timing APIs
High-Resolution Time Introduction All of the metrics that participate in the Performance Timeline are able to provides timing data in sub-millisecond resolution, i.e. in DOMHighResTimeStamp, which is defined by the High Resolution Time (L2) spec. Monotonic Clock In early stages of design, our Timing APIs were defined in terms of wall-clock epoch times. Unfortunately, such times on modern computer
次世代Webカンファレンス「HTTP2」レポート #nextwebconf | DevelopersIO
こんにちは、虎塚です。 10月18日(日)、次世代 Web カンファレンスに行ってきました。イベントの趣旨は「「次世代 Web カンファレンス」を開催します - Block Rockin’ Codes」で公開されています。 午後2つめのセッション「http2」に参加したので、取ったメモを共有します。 オーナー: @Jxck_さん @jovi0608さん @tatsuhiro_tさん @kazuhoさん 2015年はHTTP2が登場 ——Jxck_さん：HTTP2のRFCが今年出ましたけど、現状をふりかえってもらえますか。 jovi0608さん：2015年5月にRFC 7540 - Hypertext Transfer Protocol Version 2 (HTTP/2)とRFC 7541 - HPACK: Header Compression for HTTP/2でHTTP2の仕様化が完
次世代Webカンファレンス「サーバーサイドパフォーマンス」レポート #nextwebconf | DevelopersIO
こんにちは、虎塚です。 10月18日(日)、次世代 Web カンファレンスへ行ってきました。イベントの趣旨は「「次世代 Web カンファレンス」を開催します - Block Rockin’ Codes」で公開されています。 最初のセッション「server_perf (サーバーサイドパフォーマンス)」に参加してメモを取ったので、共有します。 オーナー: @mirakuiさん クックパッドでインフラ担当 @xcirさん ゲーム屋さんでインフラ担当 @cubicdaiyaさん メルカリでインフラ担当 登壇者の紹介 mirakuiさん：サーバサイドパフォーマンスというセッションは、次世代Webの文脈では話題選びがむずかしい。サーバサイドアーキテクチャもモニタリングも別にセッションがあるので、Webのパフォーマンスの話に絞る必要があった。そんな話ができる方ということで、xcirさんとcubicdai
開発環境のパフォーマンスチューニング - クックパッド開発者ブログ
こんにちは。技術部の吉川です。 クックパッドでは、ユーザーが快適にサービスを利用できるように本番環境でのパフォーマンスを向上させるための様々な工夫がなされています。 ところでパフォーマンスを気にするのは本番環境だけで良いのでしょうか？ 開発環境に目を向けると、そこにもユーザーがいます。開発者です。開発環境のパフォーマンスが向上することで、開発者が快適にサービスを開発できるようになります。 今回はそういった開発環境でのパフォーマンス向上のための取り組みについてご紹介します。 ※ なお先日 Ruby2.2化されました が、今回紹介するものはそれ以前に実施されたため、Ruby2.2で同じ結果になるとは限りません。 状況 今回対象とするのはcookpad.comのアプリケーションです。 近年はMicroservices化を進めていますが、それでも本体のレシピサービスのアプリケーションは依然として非
Railsパフォーマンス基本のキ
Railsのパフォーマンスについてよくある問題とそれに対して戦いを挑むために必要なもの。
Nginxのパフォーマンスを極限にするための考察 - Qiita
ピクセルトラッキングを想定した設定で、Nginx on EC2(c3.large) という環境で、極限まで設定をして、どれぐらいさばけるのか運用中、パフォーマンステストしてる時は、別のところに問題があり、Nginx自体の性能限界までテストできなかったので、実際どこまでいけるのかは計測できてない。 秒間1万とか2万は行けてたと思う、ちなみに実際の運用では秒間9000以上とかを記録していて、サーバ自体にはかなり余裕があるので、記録はまだまだ伸びると思う。 ちなみに empty_gif は応答が短すぎて、Nginx の $request_time では記録できない... 全部 "0.000" だから、どれぐらい掛かってるのか分からん...。 nginx.confの設定 user nginx; worker_processes auto; error_log /var/log/nginx/erro
HTTP/2時代のウェブサイト設計 - YAPC::Asia Tokyo 2015
2015年5月の RFC 化完了以降、主要なウェブブラウザの HTTP/2 対応が急速に進んでいます。今年末までには、HTTPS トラフィックの過半は HTTP/2 を利用するようになるでしょう。 本セッションでは、先進的な HTTP/2 サーバとして注目されている H2O の主開発者である奥一穂が、HTTP/2 策定の背景と HTTP/1.1 に対する優位性、HTTP/2 時代にむけたウェブサイト設計のポイントについて説明します。 Since the completion of the standardization process in May 2015, Web browser vendors are rushing to support HTTP/2. It is likely that the majority of HTTPS traffic will be using HTT
Kazuho's Weblog: ウェブページの描画 (first-paint) までの時間を測定するツールを作った件、もしくはHTTP2時代のパフォーマンスチューニングの話
ウェブページの描画 (first-paint) までの時間を測定するツールを作った件、もしくはHTTP2時代のパフォーマンスチューニングの話 ウェブページの表示までにかかる時間をいかに短くするかってのは、儲かるウェブサイトを構築する上で避けて通れない、とても重要な要素です。 少し古いデータとしては、たとえば、ウェブページの表示が500ミリ秒遅くなると広告売上が1.2%低下するというBingの例なんかも知られているわけです。 「ウェブページの表示までにかかる時間」と言った場合、実際には以下のようないくつかのメトリックがあります。 イベント 意味
What's new in Chrome DevTools?
📹Video: https://www.youtube.com/watch?v=XpGa6IzmmQg Presented at FITC Web Unleashed 2015, Toronto. As the complexity of the web apps you build keeps moving, so do the Chrome DevTools. In this session, I will give you the latest update on your favourite companion; exploring new features in performance profiling, animation inspection and updates to the JavaScript editing workflow with V8. You’ll wa
[Ruby] Ruby 3.0 の特大の非互換について - まめめも
タイトルは釣りです。すみません。Ruby 3.0 はかなり先の将来の話なので、最終的にどうなるかはわかりません。でも Ruby 3.0 に重大な変更が予定されているのは事実なので、一緒に考えて欲しいと思います。 immutable string literal Ruby 3.0 では文字列リテラルをデフォルトで immutable （破壊的変更不可） にする、という方針が『決定』しました。(Feature #11473: Immutable String literal in Ruby 3) つまり、次のようなプログラムが動かなくなります。(当チケットから少し改変して引用） sql = "SELECT #{sec_id}, pt.path, st.doc_count " sql << "FROM #{stats_tablename} AS st " #### ←ここで例外: can't m
![[Ruby] Ruby 3.0 の特大の非互換について - まめめも](https://cdn-ak-scissors.b.st-hatena.com/image/square/41a89fcb974590a4899db1f15a2fdeffe4b3148f/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117126965966783%2F17680117126965970435%2F1550317722)
だいありー (2015-10-05)
答え合わせ。 おっと、実時間だと、世代別 GC を、ちゃんと有効にしているやつと、あまり変わりませんね。 とありますが、system time が長いですよね。これ、システムからメモリを確保するために必要となる時間です、多分。800MB 以上ぶんどらないといけないですから。この場合、user 時間を比べて、GC の影響を見ておくのが良いでしょう。つまり、GC の影響は 1.64 sec - 1.47 = 0.17 sec。これが、GC による影響だとみることが出来ます。 まとめると、大ざっぱに オブジェクトの生成 0.7 sec GC 時間 0.2 sec という感じです。潰すべきオーバヘッドはどちらか、というのは、わかりやすい。GC は本当に遅いんですかね。 あと、オブジェクトを 100M 個作っておいた、すぐあとのベンチマークでは、また違った様子ですね。これも、OS とのやりとりやら、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
nginxのパフォーマンスチューニング
