Maglev - V8’s Fastest Optimizing JIT · V8
In Chrome M117 we introduced a new optimizing compiler: Maglev. Maglev sits between our existing Sparkplug and TurboFan compilers, and fills the role of a fast optimizing compiler that generates good enough code, fast enough. Background # Until 2021 V8 had two main execution tiers: Ignition, the interpreter; and TurboFan, V8’s optimizing compiler focused on peak performance. All JavaScript code is
WasmerのWinterJSのベンチマーク結果はあやしい - laiso
「WinterJS 1.0」の記事がシェアされていたので読んでいたのだけど「Bunより速くなった」と書かれていたので何事と思ってチェックしてみた wasmer.io ベンチマークの文書は以下に公開されている github.com で、まずエラーがめっちゃ出てる Socket errors: connect 155, read 108, write 0, timeout 29 それはいいとして（よくないが）、肝心なところはJarred Sumnerも指摘しているけどwrk -t12 -c400でリクエストの並列処置性能を測っているというのに違和感がある They’re benchmarking their HTTP server running on 12 cores compared to Bun running on 1 core— Jarred Sumner (@jarredsumne
Introducing Deopt Explorer - TypeScript
Over the past few months, during the lead-up to the TypeScript 5.0 beta, our team spent a good portion of our time looking for ways to improve the performance of our compiler so that your projects build faster. One of the ways we improved was by looking into an oft overlooked aspect of many JavaScript VMs: inline caching. A Brief Primer on Inline Caching Inline caching is an optimization often use
How we made Vite 4.3 faaaaster
How we made Vite 4.3 faaaaster 🚀 Just like @sapphi-red said, Vite 4.3 has made amazing performance improvements over Vite 4.2. These benchmarks based on a large project with 1000 react components. And these react components were transformed by vite-plugin-react and vite-plugin-react-swc. As a new rookie on the team, I am so glad that I've joined this party. To let more people know what we did to
Optimizing third-party script loading in Next.js | Blog | Chrome for Developers
Around 45% of requests from websites served on mobile and desktop are third-party requests of which 33% are scripts. The size, latency, and loading of third-party scripts can significantly affect a site's performance. The Next.js Script component comes with baked-in best practices and defaults to help developers introduce third-party scripts in their applications while addressing potential perform
2022年におけるフロントエンド開発のベースライン
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog TL;DR:2022にフロントエンド開発で最も考慮すべきユーザー環境は、パフォーマンスでは低スペックのAndroid端末、標準仕様では2年前のSafari、そしてネットワークでは４Gです。それに対してはJSへの過剰依存などが原因で主にパフォーマンスの面でのウェブ全体の対応がよくありません。 こんにちは！LINEフロントエンド開発室のダバロス アランです。この記事のタイトルを見て「釣りタイトルですね〜」と考えている方がいると思いますが今回に限ってはそれを大目に見てください。それはなぜかと言いますと、2021年から2022年にかけて私たちフロントエンドエンジニアが全体的に考え方を改める必要が出るほど大きな変化がありました。 その変
JS のビルドサイズを極限まで絞るための TIPS 集
ビルドサイズ限界まで絞りたい人向け。 あらゆる環境で実践するものではないが、知ってたら簡単に避けることができるのもあるので知っておくと便利なTIPS書いていく。 基本ポリシー 未使用コードはビルド時に全部落とす。 何が未使用コードで、何が定数かわかるようなインターフェースを人間が心がける。 用語 Dead Code Ellimination(DCE) Rollup や Terser で、未使用コードを削除すること
Chrome Devtools による フロントエンドパフォーマンスの計測
こんにちは。株式会社スタメンでFANTSのフロントエンドを担当している@0906kokiです。 今回の記事では、皆さんおなじみの Chrome Devtools にある Performance タブで、フロントエンドのパフォーマンスを計測する方法について書きたいと思います。 はじめに フロントエンドのパフォーマンス・チューニングと言うとバックエンドと比べて後回しになりがちですが、フロントエンドにアプリケーションの複雑性が寄ってきている現在、フロントエンドがボトルネックでレスポンスのレイテンシーが発生することは往々にしてあると思います。 バックエンドではユーザー数の増加や大量の同時接続に耐えられる負荷対策やパフォーマンス・チューニングが中心となりますが、フロントエンドではプロジェクトサイズの増加による JavaScript ファイルのダウンロードやスクリプティング、レンダリング速度の低下等が
今Partytownがヤバい。JavaScript Sandboxの未来はどっちだ？
概要 Partytownというプロジェクトが先月発表された。このプロジェクト自体はWebのパフォーマンス向上(3rd Party Scriptによるブロッキングの低減)を主目的としているが、実質ブラウザにおけるJavaScript Sandboxの方向性に一石を投じるものであるとして自分は理解した。本稿ではこちらについて背景とともに解説を試みる。 WebブラウザにおけるJavaScript Sandbox JavaScriptで記述されたWebアプリケーションにおいて、たとえばプラグイン機構を実現したいなど、他Partyが提供あるいはユーザ自身が記述したスクリプトを、ホストとなるアプリケーションに影響を与えることなく実行することを許可したい、というケースはままある。2000年代に跋扈したブログパーツの類はWebコンテンツに対するプラグインの代表例とも言えるが、埋め込み先ページに対しての全権
Web版WINTICKETのパフォーマンスを改善してきた | CyberAgent Developers Blog
はじめに Web フロントエンドエンジニアとして株式会社 WinTicket で内定者アルバイトをしていた佐々木です。 この記事では1ヶ月の成果を紹介します。 内定者アルバイト期間中は、主にパフォーマンス改善を行いました。パフォーマンスは世の中的に Core Web Vitals の影響で注目が集まっており、ユーザー視点および事業視点でとても重要な要素となっています。 大雑把にパフォーマンス改善というと様々な文脈を持ちますが、今回はリソースの初期読み込みの速度を改善することを目的として、JavaScript のファイルサイズ (バンドルサイズ)を削減しました。 WINTICKET では React と Node.js を用いて Isomophic なアプリケーションを作っています。 しかし、アプリケーションが大きくなるにつれてバンドルサイズが肥大化しており、改善が必要な状況でした。そのため
JavaScriptでのDOM操作は重いのかという話とForced Synchronous Layoutについて - id:anatooのブログ
2015年にもなるのにJavaScriptでのDOM操作のパフォーマンスについて書く。ウェブページにインタラクションを持たせたい時に、JavaScriptでDOM操作を行うことがよくある。このDOM操作のパフォーマンスについて、よく聞く意見を大別すると次の2つがある。 JavaScriptによるDOM操作は重たい レンダリングが重いだけで、DOM操作そのものはそれほど重たくない JavaScriptでオブジェクトのプロパティを操作したりする単体の処理は通常1ミリ秒もかからないが、DOM操作をするとレンダリングが完了するまでに数十ミリ秒程度かかったりする場合がある。1番目のDOM操作が重たいと言っている人は経験則的にそう言っていることが多い。 レンダリングの仕組みを知っている人は2番目の意見を言うが、重箱の隅をつつくような話をするとこれも必ずしも正しいわけではない。DOM操作するコードによっ
Building the Google Photos Web UI
A few years ago I had the privilege of being an engineer on the Google Photos team and part of the initial launch in 2015. A lot of people contributed to the product — designers, product managers, researchers, and countless engineers (across Android, iOS, Web, and the server) to name just some of the major roles. My responsibility was the web UI, and more specifically the photo grid. We wanted to
Node.jsのパフォーマンスチューニングのtips - hiroppy's site
Node v9.0.0 (Current) | Node.js Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine. 今回は Node 単体の話なので、Express、Nginx 等のチューニングに関してはココには書きません。 また、libuv 等のコード内部の話もしません。 —inspect, —inspect-brk もともとあった、--debugから移行されました。(v8.0.0 ~) Chrome を使いデバッグ、プロファイリング等を使えるようになります。 ブラウザで使えるので、いつも使っている感じと同じです。 --inspect-brkは--debug-brkと同様に最初の行にブレークポイントを設置し、起動します。 $ node --inspect test.js Debugger lis
Web VitalsとJavaScript Errorの可視化
こんにちは、@watilde です。Amplifyの開発者体験体験の向上をすべく、ツイートのウォッチやGitHubでの反応などしています。もう去年のことですが、最近はcliの改善としてcreate-react-appのようにinitの実行時にREADMEの生成を行うPRなど作ったりしてます。参考: aws-amplify/amplify-cli#5808 この記事は英語で書いた Improve UX by observability in front-end with Amplify and QuickSight を自分で日本語に意訳してみたものです。Node学園 35時限目 オンライントライアル でも同様の内容を発表予定です。 JavaScriptのエラー例 JavaScriptは100%動いているのか 私達の作るWebアプリ・Webサイトが様々なデバイスで100％動作しているかは、実態
【LINE証券 Frontend】requestIdleCallbackを活用して初期レンダリング時間を約14%削減した話
こんにちは。フィナンシャル開発センターの鈴木です。LINE証券のフロントエンドを担当しています。この記事は【LINE証券 FrontEnd】シリーズの4番目の記事です。 最近のWeb Vitalsの隆盛を受けて、LINE証券のフロントエンドでもパフォーマンスの改善に取り組み始めました。およそ2週間ほど改善に取り組んだ結果として、開発環境での計測ではLighthouseのperformanceスコアが従来より30点ほど上昇しました。 パフォーマンス改善のためにさまざまな施策を行いましたが、この記事ではその中でも興味深かったものとして、requestIdleCallbackを活用してLazy Loadingされるコンポーネントの読み込みを遅延し、その結果初期レンダリングにかかる時間を約14%削減できた事例をご紹介します。 環境 以前の記事でご紹介したとおり、LINE証券のフロントエンドはTyp
Lazy Load Routes in Vue with webpack Dynamic Comments | CSS-Tricks
The way routing works in JavaScript is usually that you specify which relative URL pattern you want for which component to render. So for /about you want the <About /> component to render. Let’s take a look at how to do this in Vue/Vue Router with lazy loading, and do it as cleanly as possible. I use this little tip all the time in my own work. A repo that includes everything covered in this post
React Server Components 総まとめ
先日、React Server Componentsについてまとめる機会がありました。 この記事では、React Server Componentsの概要と、デモを触る中で感じたことについてご紹介します。 React Server Componentsとは React Server Componentsは、Reactコンポーネントをサーバーサイドでレンダーする新しい技術です。 一部のコンポーネントをサーバーサイドでレンダーしてしまうことで、アプリケーションのパフォーマンスを上げることを目的とします。 図は、デモの画面のうち、サーバーでレンダーされる部分を青で、クライアントでレンダーされる部分を赤で示したものです。 ページ全体をサーバーでレンダーするのではなく、一部のコンポーネントはクライアントにレンダーさせていることがわかります。 また、React Server ComponentsはCo
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Chrome Platform Status
バンドル最適化マニアクス at tfconf
Measuring Bundle Sizes with Next.js and GitHub Actions