OpenTelemetry でブラウザを計装する方法が公式ドキュメントに書かれていて、その中に次のような記述がある。 opentelemetry.io <!-- https://www.w3.org/TR/trace-context/ Set the `traceparent` in the server's HTML template code. It should be dynamically generated server side to have the server's request trace ID, a parent span ID that was set on the server's request span, and the trace flags to indicate the server's sampling decision (01 = sampled,
The Year Ahead (2026) January 24, 2026 We haven't had a blog post in a while, largely due to the holiday season but also because many of us have been hard at work on some fairly chunky e18e projects lately! So let's have a look ahead at what's coming in 2026 and a small recap on what we got up to last year 🚀 2025 Recap In 2025, we saw a great number of contributions, new projects, and milesto
LogRocket’s Galileo AI watches every session, surfacing impactful user struggle and key behavior patterns. Zod is the undisputed king of TypeScript validation. In a remarkably short time, it has become the gold standard, celebrated across the ecosystem for its phenomenal developer experience, elegant chainable API, and robust type inference. For countless developers, Zod is not just a library — it
Earlier this year we asked for input from the community to inform design for Oxlint support for custom JS plugins. Today, we are pleased to announce the result of many months of research, prototyping, and finally building: Oxlint supports plugins written in JS! Key features ESLint-compatible plugin API. Oxlint will be able to run many existing ESLint plugins without modification.An alternative AP
この記事は、静的解析とビルドサイズ面で興味深いテーマでした。記事として自分の考えを書きます。 注意。あくまでビルドパフォーマンス視点での最適化です。強い意図があって、自分のドメインモデリングの方法論ではこれが最適なんだ、というなら元コードの方法論を止めるつもりはありません。 元記事のコードを minify するとどうなるか 元コードを参考に、それにアクセスするサンプルコードを書いてみます。 const sortingOptions = { priceDesc: { id: "priceDesc", sort: "price", order: "desc", label: "価格が高い順", }, priceAsc: { id: "priceAsc", sort: "price", order: "asc", label: "価格が安い順", }, ratingDesc: { id: "ra
Show navigation 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 Jav
「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コンテンツに対するプラグインの代表例とも言えるが、埋め込み先ページに対しての全権
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
