Optimizing WebKit & Safari for Speedometer 3.0
The introduction of Speedometer 3.0 is a major step forward in making the web faster for all, and allowing Web developers to make websites and web apps that were not previously possible. In this article, we explore ways the WebKit team made performance optimizations in WebKit and Safari based on the Speedometer 3.0 benchmark. In order to make these improvements, we made an extensive use of our per
romgrk
I often feel like javascript code in general runs much slower than it could, simply because it’s not optimized properly. Here is a summary of common optimization techniques I’ve found useful. Note that the tradeoff for performance is often readability, so the question of when to go for performance versus readability is a question left to the reader. I’ll also note that talking about optimization n
フロントエンドパフォーマンスの変遷とNext.jsに見る次の時代
こちらのイベントのLT登壇資料です。 https://ochacafe.connpass.com/event/308830/ 登壇後、資料内の論理展開を登壇者の判断で改善しております。以下は登壇時からの主な修正点です。 ・レガシーMPAについて、FCPのみに着目して初回表示が遅いとしていた記述を削除 ・レガシーMPA + Ajaxについて、初回表示に関する言及を削除。SPAで行われる初回表示に関する変化の説明と重複するため ・SPAの初回表示について、FCPが速くなったとポジティブな書き方を、逆にLCPが遅くなったとのネガティブな記述に修正 ・SPA+SSRのページを削除。サーバーサイドフェッチを伴うSSRについてはNext.js側のページで解説 ・サーバーサイドフェッチを伴うSSRについてのネガティブな記述を削除し、SPA的なクライアントサイドフェッチのアーキテクチャとフラットに取り扱う
Speedometer 3.0: The Best Way Yet to Measure Browser Performance
As announced on browserbench.org today, in collaboration with other browser engine developers, Apple’s WebKit team is excited to introduce Speedometer 3.0, a major update that better reflects the Web of today. It’s built together by the developers of all major browser engines: Blink, Gecko, and WebKit with hundreds of contributions from companies like Apple, Google, Intel, Microsoft, and Mozilla.
【LINE証券 Frontend】requestIdleCallbackを活用して初期レンダリング時間を約14%削減した話
こんにちは。フィナンシャル開発センターの鈴木です。LINE証券のフロントエンドを担当しています。この記事は【LINE証券 FrontEnd】シリーズの4番目の記事です。 最近のWeb Vitalsの隆盛を受けて、LINE証券のフロントエンドでもパフォーマンスの改善に取り組み始めました。およそ2週間ほど改善に取り組んだ結果として、開発環境での計測ではLighthouseのperformanceスコアが従来より30点ほど上昇しました。 パフォーマンス改善のためにさまざまな施策を行いましたが、この記事ではその中でも興味深かったものとして、requestIdleCallbackを活用してLazy Loadingされるコンポーネントの読み込みを遅延し、その結果初期レンダリングにかかる時間を約14%削減できた事例をご紹介します。 環境 以前の記事でご紹介したとおり、LINE証券のフロントエンドはTyp
Million Lint is in public beta | Million.js
Million Lint is in public betaAiden Bai (opens in a new tab), John Yang (opens in a new tab), Nisarg Patel (opens in a new tab) – February 29, 2024 It’s launch time. After three months and hundreds of commits, we invite you to try out Million Lint. The experience is not finished – there are a few known bugs and several missing features – but we are really happy with how it's shaping up and couldn'
FOSDEM 2024 - Fast JavaScript with Data-Oriented Design
FOSDEM 2024/Schedule/Events/Developer rooms/Web Performance/Fast JavaScript with Data-Oriented Design Let’s squeeze the last bits of performance out of JS so that we can crunch massive amounts of data! In this presentation I will describe what I learned while optimizing the Firefox Profiler. The Firefox Profiler is a web application which needs to handle large profiles containing hundreds of thous
3Dモデルの配信サーバーでRustとZstandardを採用して数倍のパフォーマンス向上を実現した - pixiv inside
はじめに こんにちは、VRoid部所属のエンジニアのyueです。 この度VRoid Hubで3Dモデルの配信サーバーの見直しを行い、技術選定から始めRustとZstandard (zstd)を採用した実装に切り替えました。 結論から見るに従来のNode.js製サーバーと比べて以下のことを実現しました。 最大のレスポンス時間が 1.5 ~ 2.5s から 300 ~ 400msまで低下 平均のレスポンス時間が 700 ~ 800ms から 150 ~ 200msまで低下 サーバーのCPU使用率が ~ 50% から ~ 10%まで低下 docker image のサイズが ~ 346mb から ~ 21mb程度まで削減 配信されるファイルサイズが平均 10 ~ 20% 軽量化されました レスポンス時間 CPU使用量 (上からAVG(MAX), AVG, AVG(MIN)) メモリー使用量に関し
2024-02-05のJS: TypeScript 5.4 Beta、Learn Testing/Performance、Interop 2024
JSer.info #679 - TypeScript 5.4 Betaがリリースされました。 Announcing TypeScript 5.4 Beta - TypeScript クロージャーにおけるNarrowing結果の改善、NoInfer Utility Typeが追加されています。 また、ES2024のObject.groupBy/Map.groupByをサポート、Import Attributesのサポートが追加されています。 そのほかには、target: "ES3"やoutオプションなどを非推奨として、次のTypeScript 5.5で削除されることがアナウンスされています。TypeScript 5.5で削除されるオプションは、次のIssueにまとめられています。 Feedback: 5.0 deprecations · Issue #51909 · microsoft/T
ソフト ナビゲーションの測定実験 | Web Platform | Chrome for Developers
Core Web Vitals イニシアチブでは、リリース以来、ウェブサイトの作成や読み込みの背後にある技術的詳細ではなく、ウェブサイトの実際のユーザー エクスペリエンスを測定することを目標としてきました。Core Web Vitals の 3 つの指標は、ユーザー中心の指標として作成されました。これらは既存の技術的指標（DOMContentLoaded や load など）を進化させたもので、ページのパフォーマンスに対するユーザーの感じ方とは無関係であることが多い時間を測定したものです。そのため、サイトのパフォーマンスが良好であれば、サイトの構築に使用されたテクノロジーがスコア判定に影響することはありません。 現実は理想的よりも常に少し複雑で、人気のあるシングルページ アプリケーション アーキテクチャがウェブに関する主な指標の指標で完全にサポートされていることは一度もありません。このよう
The Performance Inequality Gap, 2024 - Infrequently Noted
The global device and network situation continues to evolve, and this series is an effort to provide an an up-to-date understanding for working web developers. So what's changed since last year? And how much HTML, CSS, and (particularly) JavaScript can a new project afford? The Budget, 2024 JavaScript-Heavy Markup-Heavy Calculate Your Own Situation Report Mobile Desktop Takeaways The Great Branch
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
lorenzofox blog | Template engine with streaming capability - part 1/2
Chrome Platform Status
perf: improve performance of Link and routes by chorobin · Pull Request #1453 · TanStack/router
Performance tooling in 2024 and beyond | Blog | Chrome for Developers
Booking.com Doubles Delivery Performance Using DORA Metrics and Micro Frontends
DORA Metrics At Work
Learn Performance | web.dev
Transfer Budgets
The Golden Rule of Web Performance and Different Performance Engineering Specializations