この記事は、静的解析とビルドサイズ面で興味深いテーマでした。記事として自分の考えを書きます。 注意。あくまでビルドパフォーマンス視点での最適化です。強い意図があって、自分のドメインモデリングの方法論ではこれが最適なんだ、というなら元コードの方法論を止めるつもりはありません。 元記事のコードを minify するとどうなるか 元コードを参考に、それにアクセスするサンプルコードを書いてみます。 const sortingOptions = { priceDesc: { id: "priceDesc", sort: "price", order: "desc", label: "価格が高い順", }, priceAsc: { id: "priceAsc", sort: "price", order: "asc", label: "価格が安い順", }, ratingDesc: { id: "ra
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
「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
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 🚀 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
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
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog TL;DR:2022にフロントエンド開発で最も考慮すべきユーザー環境は、パフォーマンスでは低スペックのAndroid端末、標準仕様では2年前のSafari、そしてネットワークでは４Gです。それに対してはJSへの過剰依存などが原因で主にパフォーマンスの面でのウェブ全体の対応がよくありません。 こんにちは！LINEフロントエンド開発室のダバロス アランです。この記事のタイトルを見て「釣りタイトルですね〜」と考えている方がいると思いますが今回に限ってはそれを大目に見てください。それはなぜかと言いますと、2021年から2022年にかけて私たちフロントエンドエンジニアが全体的に考え方を改める必要が出るほど大きな変化がありました。 その変
ビルドサイズ限界まで絞りたい人向け。 あらゆる環境で実践するものではないが、知ってたら簡単に避けることができるのもあるので知っておくと便利なTIPS書いていく。 基本ポリシー 未使用コードはビルド時に全部落とす。 何が未使用コードで、何が定数かわかるようなインターフェースを人間が心がける。 用語 Dead Code Ellimination(DCE) Rollup や Terser で、未使用コードを削除すること
こんにちは。株式会社スタメンでFANTSのフロントエンドを担当している@0906kokiです。 今回の記事では、皆さんおなじみの Chrome Devtools にある Performance タブで、フロントエンドのパフォーマンスを計測する方法について書きたいと思います。 はじめに フロントエンドのパフォーマンス・チューニングと言うとバックエンドと比べて後回しになりがちですが、フロントエンドにアプリケーションの複雑性が寄ってきている現在、フロントエンドがボトルネックでレスポンスのレイテンシーが発生することは往々にしてあると思います。 バックエンドではユーザー数の増加や大量の同時接続に耐えられる負荷対策やパフォーマンス・チューニングが中心となりますが、フロントエンドではプロジェクトサイズの増加による JavaScript ファイルのダウンロードやスクリプティング、レンダリング速度の低下等が
概要 Partytownというプロジェクトが先月発表された。このプロジェクト自体はWebのパフォーマンス向上(3rd Party Scriptによるブロッキングの低減)を主目的としているが、実質ブラウザにおけるJavaScript Sandboxの方向性に一石を投じるものであるとして自分は理解した。本稿ではこちらについて背景とともに解説を試みる。 WebブラウザにおけるJavaScript Sandbox JavaScriptで記述されたWebアプリケーションにおいて、たとえばプラグイン機構を実現したいなど、他Partyが提供あるいはユーザ自身が記述したスクリプトを、ホストとなるアプリケーションに影響を与えることなく実行することを許可したい、というケースはままある。2000年代に跋扈したブログパーツの類はWebコンテンツに対するプラグインの代表例とも言えるが、埋め込み先ページに対しての全権
はじめに Web フロントエンドエンジニアとして株式会社 WinTicket で内定者アルバイトをしていた佐々木です。 この記事では1ヶ月の成果を紹介します。 内定者アルバイト期間中は、主にパフォーマンス改善を行いました。パフォーマンスは世の中的に Core Web Vitals の影響で注目が集まっており、ユーザー視点および事業視点でとても重要な要素となっています。 大雑把にパフォーマンス改善というと様々な文脈を持ちますが、今回はリソースの初期読み込みの速度を改善することを目的として、JavaScript のファイルサイズ (バンドルサイズ)を削減しました。 WINTICKET では React と Node.js を用いて Isomophic なアプリケーションを作っています。 しかし、アプリケーションが大きくなるにつれてバンドルサイズが肥大化しており、改善が必要な状況でした。そのため
2015年にもなるのにJavaScriptでのDOM操作のパフォーマンスについて書く。ウェブページにインタラクションを持たせたい時に、JavaScriptでDOM操作を行うことがよくある。このDOM操作のパフォーマンスについて、よく聞く意見を大別すると次の2つがある。 JavaScriptによるDOM操作は重たい レンダリングが重いだけで、DOM操作そのものはそれほど重たくない JavaScriptでオブジェクトのプロパティを操作したりする単体の処理は通常1ミリ秒もかからないが、DOM操作をするとレンダリングが完了するまでに数十ミリ秒程度かかったりする場合がある。1番目のDOM操作が重たいと言っている人は経験則的にそう言っていることが多い。 レンダリングの仕組みを知っている人は2番目の意見を言うが、重箱の隅をつつくような話をするとこれも必ずしも正しいわけではない。DOM操作するコードによっ
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 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
こんにちは、@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％動作しているかは、実態
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
