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
こんにちは。フィナンシャル開発センターの鈴木です。LINE証券のフロントエンドを担当しています。この記事は【LINE証券 FrontEnd】シリーズの4番目の記事です。 最近のWeb Vitalsの隆盛を受けて、LINE証券のフロントエンドでもパフォーマンスの改善に取り組み始めました。およそ2週間ほど改善に取り組んだ結果として、開発環境での計測ではLighthouseのperformanceスコアが従来より30点ほど上昇しました。 パフォーマンス改善のためにさまざまな施策を行いましたが、この記事ではその中でも興味深かったものとして、requestIdleCallbackを活用してLazy Loadingされるコンポーネントの読み込みを遅延し、その結果初期レンダリングにかかる時間を約14%削減できた事例をご紹介します。 環境 以前の記事でご紹介したとおり、LINE証券のフロントエンドはTyp
Jacob Groß (@kurtextrem@webperf.social, @kurtextrem) is a passionate Software Engineer who loves all topics related to webperf, UX & security. Currently Principal Software Engineer at JSMD Group, based in Munich, Germany. Server-rendered Redux apps commonly have to transfer the store state from the server to the client. Transferring large states can be slow, so in 2019, Henrik Joretag benchmarked
Stéphane Goetz (@onigoetz) is a performance enthusiast. Working on developer tooling, frontend libraries, and architecture as Principal Software Engineer at Swissquote Bank. Introduction I wish to bring you with me on a journey to learn about optimizing a library for localization, I would like to share my learnings with you on benchmarking, profiling, and optimizing. At Swissquote Bank, we use cli
Hey, I'm Fabio and I've been contracted by the Prettier team to speed up Prettier's command line interface (CLI). In this post we'll take a look at the optimizations I've discovered, the process that lead to finding them, some exciting numbers comparing the current CLI with the new one, and some guesses about what could be optimized next. Installation The new work-in-progress CLI for Prettier has
Speedometer 3 is a cross-industry effort to build a modern browser benchmark rooted in real-world user experiences. Its goal is to focus browser engineering effort towards making the Web more smooth for actual users on actual pages. This is hard to do and most browser benchmarks don’t do it well, but we see it as a unique opportunity to improve responsiveness broadly across the Web. This requires
Please don't import SVGs as JSX. It's the most expensive form of sprite sheet: costs a minimum of 3x more than other techniques, and hurts both runtime (rendering) performance and memory usage. This bundle from a popular site is almost 50% SVG icons (250kb), and most are unused. SVGs in JS have a cost and SVGs don’t belong into your JS bundle. It’s about time to bring back SVG-in-HTML. Let’s take
Our team is a couple of months into developing a new application, and our suite of unit 240 tests takes 46 seconds to run. That duration is not excessive yet, but it’s increasing in proportion to the number of tests. In a couple of months, it’ll take a couple of minutes to run our tests. We were surprised by this, as Jest is known for its fast performance. However, while Jest reported that each te
10 January, 2023 Why Not document.write()? Written by Harry Roberts on CSS Wizardry. Table of Contents What Makes Scripts Slow? The Preload Scanner document.write() Hides Files From the Preload Scanner What About Async Snippets? document.write() Executes Synchronously Is It All Bad? Early document.write() Late document.write() It Gets Worse… Avoid document.write() If you’ve ever run a Lighthouse t
Whilst the trend is seemingly to rewrite every JavaScript build tool in other languages such as Rust or Go, the current JavaScript-based tools could be a lot faster. The build pipeline in a typical frontend project is usually composed of many different tools working together. But the diversification of tools makes it a little harder to spot performance problems for tooling maintainers as they need
Published: September 30, 2022, Last updated: December 19, 2024 Common advice for keeping JavaScript apps fast tends to boil down to the following advice: "Don't block the main thread." "Break up your long tasks." This is great advice, but what work does it involve? Shipping less JavaScript is good, but does that automatically equate to more responsive user interfaces? Maybe, but maybe not. To unde
ユーザーの直帰率や離脱率とパフォーマンスの関係から、コンテンツを表示する速度や応答性（ページがユーザー入力に応答する速度）がいかに重要であるかは、既によく知られるようになってきています。 ではコンテンツを表示する速度や応答性を上げるにはどうしたらいいでしょう。 結論から述べるとパフォーマンスを客観的な指標に基づいて正確かつ定量的に測定し、そこから課題を見つけて解決することが必要になります。 GoogleはChrome User Experience Reportに新しく応答性指標INPを導入しました。 INPとは INP（Interaction to Next Paint）は、ページの読み込みを開始してからユーザーがページを離れるまでの間に発生するユーザー入力の応答性（インタラクション）を評価する測定基準で、遅延時間を計測します。 計測対象のインタラクションは、以下となります。 ユーザー入
課題link お手伝いしているシステムでNestJSを採用しているバックエンドのテストが遅いという課題があったので対処した。 前提link フレームワークDBテストランナーその他 テストの総数は700弱。 最終結果link 最終的には2段階の改修を経てローカルのテストが3倍速程度高速化した。 # before Test Suites: 145 passed, 145 total Tests: 2 skipped, 681 passed, 683 total Snapshots: 0 total Time: 925.063 s Ran all test suites. Done in 926.48s. # ts-jestを@swc/jestに置き換えた Test Suites: 145 passed, 145 total Tests: 2 skipped, 681 passed, 683 t
@1000ch (id:hc0001) です。技術顧問業としては広報周りの戦略を考えていることが多いのですが、今日はエンジニアリングの話です。 ドクターズプライムのプロダクト開発の中でも、パフォーマンス上の課題を発見して改善に取り組むことがあります。今回は @oinume (id:oinume) さんから 「この辺りの実装が問題になっていそう…」 という相談があったので、私がアプリケーション全体を眺めてボトルネックになっている箇所をいくつかピックアップし修正方針を提案したのですが、 実装を修正する前に 「まずは継続的にモニタリングできる環境を準備してパフォーマンスの前後がわかるようにしましょう」 ということで原点回帰した話です。 Core Web Vitals でリアルユーザーモニタリング パフォーマンス指標とプロダクト KPI の選定 リアルユーザーモニタリングと合成モニタリング データ
Nic Jansma (@nicj) is a software developer at Akamai building high-performance websites, apps and open-source tools. Table of Contents The JS Self-Profiling API What is Sampled Profiling? Downsides to Sampled Profiling API Document Policy API Shape Sample Interval Buffer Who to Profile When to Profile Specific Operations User Interactions Page Load Overhead Anatomy of a Profile Beaconing Size Comp
Small Bundles, Fast Pages: What To Do With Too Much JavaScript Minimising the amount of JavaScript in your pages is an essential step to ensure a speedy user experience. This post will explain why bundle size matters and recommend tools and processes you can follow to monitor, visualise, and most importantly, shrink your JS bundles. How does bundle size affect performance? Large amounts of JavaScr
TL;DR Instead of attaching tooltips directly to document.body, attach them to a predefined div in document.body. BAD <body> <!-- temporary div, vanishes when tooltips vanishes --> <div>my tooltip</div> <body> GOOD <body> <!-- this div stays forever, just for attaching tooltips --> <div id="tooltips-container"> <!-- temporary div, vanishes when tooltips vanishes --> <div>my tooltip</div> </div> <bo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
