GitHub - e18e/e18eYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
e18e
Welcome to e18e! e18e (Ecosystem Performance) is an initiative to connect the folks and projects working to improve the performance of JS packages. We'd also like to provide visibility to the efforts of countless open source developers working to cleanup, levelup, and speedup our dependencies. We invite you to get involved in the different projects linked from these pages, and to connect with oth
Speeding up the JavaScript ecosystem - The barrel file debacle
Let's imagine you are working on a big project with many files. You add a new file to work on a new feature and import a function from another directory into your code. import { foo } from "./some/other-file"; export function myCoolCode() { // Pretend that this is super smart code :) const result = foo(); return result; } Excited about finishing your feature, you run the code and realize that it t
Get All That Network Activity Under Control with Priority Hints
Get All That Network Activity Under Control with Priority Hints The browser is very good at prioritizing resources requests on its own. But it's not always great. Priority hints makes it easy to provide explicit instructions as to how and in what network activity occurs. Open up the browser's network tab and you'll see a lot of activity. Assets are being downloaded, information's being submitted,
Speeding up the JavaScript ecosystem - npm scripts
If you’re working with JavaScript you’ve likely used the "scripts" field in package.json to set up common tasks for your project. Those scripts can be executed with npm run on the terminal. I noticed that I opted more and more to just call the underlying command directly instead of shelling out to npm run, mostly because it's noticeably faster. But what makes them so much slower in comparison? Tim
Speeding up the JavaScript ecosystem - eslint
We've talked quite a bit about linting in the past two posts of this series, so I thought it's time to give eslint the proper limelight it deserves. Overall eslint is so flexible, that you can even swap out the parser for a completely different one. That's not a rare scenario either as with the rise of JSX and TypeScript that is frequently done. Enriched by a healthy ecosystem of plugins and prese
Why Is My Jest Suite So Slow?
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
Why Not document.write()? – CSS Wizardry
10 January, 2023 (last updated on 1 June, 2025) 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
Using inline JavaScript modules to prevent CSS blockage
Stoyan (@stoyanstefanov) is a former Facebook and Yahoo! engineer, writer ("JavaScript Patterns", "React: Up and Running"), speaker (JSConf, Velocity, Fronteers), toolmaker (Smush.it, YSlow 2.0) and a guitar hero wannabe. Problem As the previous post puts it: A slow CSS prevents the JavaScript following it from executing. And in addition, when the JS following the CSS is inline, it’s naturally syn
JavaScript Start-up Optimization | Articles | web.dev
As we build sites more heavily reliant on JavaScript, we sometimes pay for what we send down in ways that we can’t always easily see. In this article, we’ll cover why a little discipline can help if you’d like your site to load and be interactive quickly on mobile devices. Delivering less JavaScript can mean less time in network transmission, less spent decompressing code and less time parsing and
Speeding up the JavaScript ecosystem - one library at a time
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
Integer math in JavaScript | James Darpinian
You may know that all numbers in JavaScript are 64 bit double-precision floating point values. This is sometimes convenient and it works pretty well as a default for novice programmers, who are often confused by integer math, and rightfully so when 1 / 2 = 0. Unfortunately, it makes things slow. Doubles take a lot of memory and floating point math is slower than integer math on CPUs. It's also inc
JS のビルドサイズを極限まで絞るための TIPS 集
ビルドサイズ限界まで絞りたい人向け。 あらゆる環境で実践するものではないが、知ってたら簡単に避けることができるのもあるので知っておくと便利なTIPS書いていく。 基本ポリシー 未使用コードはビルド時に全部落とす。 何が未使用コードで、何が定数かわかるようなインターフェースを人間が心がける。 用語 Dead Code Ellimination(DCE) Rollup や Terser で、未使用コードを削除すること
2022年におけるフロントエンド開発のベースライン
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog TL;DR:2022にフロントエンド開発で最も考慮すべきユーザー環境は、パフォーマンスでは低スペックのAndroid端末、標準仕様では2年前のSafari、そしてネットワークでは４Gです。それに対してはJSへの過剰依存などが原因で主にパフォーマンスの面でのウェブ全体の対応がよくありません。 こんにちは！LINEフロントエンド開発室のダバロス アランです。この記事のタイトルを見て「釣りタイトルですね〜」と考えている方がいると思いますが今回に限ってはそれを大目に見てください。それはなぜかと言いますと、2021年から2022年にかけて私たちフロントエンドエンジニアが全体的に考え方を改める必要が出るほど大きな変化がありました。 その変
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - tinylibs/tinybench: 🔎 A simple, tiny and lightweight benchmarking library!
https://blog.sentry.io/2022/07/19/javascript-sdk-package-reduced/
Frontend Web Performance: The Essentials [1]
WebAssembly vs Javascript
GitHub - nolanlawson/fuite: A tool for finding memory leaks in web apps
Unlock Performance Insights: Optimize JS with Benchmarking on HASTY
