あなたのパフォーマンスを倍にする Frontend Ops はいかがですか.md あなたのプロジェクトに Frontend Ops を。 [経営者の方へ] ウェブサイトが遅くなっていませんか?機能追加が遅くなっていませんか? 私 @mizchi は Node.js とフロントエンドのエキスパートです。もし私を知らなければ、御社のフロントエンド担当に mizchi とは誰か聞いてみてください。それが一番早いと思います。 Frontend Ops の専門家として御社のプロダクトの改善にご協力します。 Frontend Ops は、ウェブサイトのロード時間を改善したり、開発者の基盤に手を入れることで一日に何度機能を追加できるかという指標に貢献するロールです。その結果としてUXを改善し、ビジネスを前進させます。 成果報酬で、費用はざっくり 100万円*達成率 となります。(詳細は後述) 弁護士作成
⚡️ 25x faster — Switch from npm install to bun install in any Node.js project to make your installations up to 25x faster. https://bun.sh/docs/cli/install という記述を見かけて直感的に、そうはならんやろと思ったものの実際にベンチマークをしているのでどういうことなのかを気になって調べた。 A global install cache. bun installを実行すると ~/.bun/install/cache/ 以下にnpmレジストリからダウンロードされたファイルの実体が展開されキャッシュされる(--cache-dirでパスを変更できる)。 キャッシュにはパッケージのバージョンごとのディレクトリとlatestのシンボリックリンクがある。こ
When a laptop crashed in an empty office, we knew it was time to overhaul our performance testing framework. In 2018, all we needed was a single MacBook. At least, that’s all we needed to run our entire in-house performance testing system. The laptop looped the same couple of test scenarios over and over, and reported any changes and timings every hour or so to a shared dashboard. We wrote all abo
Learn how concurrent features like Transitions, Suspense, and React Server Components improve application performance. React 18 has introduced concurrent features that fundamentally change the way React applications can be rendered. We'll explore how these latest features impact and improve your application's performance. First, let's take a small step back to understand the basics of long tasks a
id:mizdra は eslint-interactive というツールをメンテナンスしています。このツールを使うと、多数の ESLint エラーを効率的に修正できます (詳しくは以前書いた記事を見てください)。 www.mizdra.net eslint-interactive では「中規模〜大規模なコードベースであってもキビキビ動く」を大事にしてます。その一環として、eslint-interactive には CI (GitHub Actions) でベンチマークを取り、以前から大きく劣化していたら CI を fail させる仕組みがあります。 https://github.com/mizdra/eslint-interactive/actions/workflows/benchmark.yml?query=is%3Afailure しかし CI で実行するためにノイズが大きく、よく
こんにちは、かたいなかです。 最近、NestJS製のGraphQLサーバでのSchemaからのTypescriptファイルの生成が遅い問題を調査する機会がありました。 今回の記事では、ツールの使い方等の自分への備忘録を兼ねて、どのように問題に取り組んだかを記事にして紹介します。 TL;DR 高速化するならまずは計測から。計測によるボトルネック特定が最優先。 フレームグラフが遅い処理を特定するのに超便利。Node.jsなら0xがフレームグラフ生成に便利。 @nestjs/graphql でGraphQLのスキーマからTypescriptのファイルを生成する処理が速くなった。 経緯 最近関わった案件では、BFFとしてNestJS製のGraphQLサーバをスキーマファーストで使用していました。GraphQLによるスキーマファーストな開発の恩恵は日々感じているものの、サーバの起動時や再コンパイルの
Rendering on the Web Stay organized with collections Save and categorize content based on your preferences. One of the core decisions web developers must make is where to implement logic and rendering in their application. This can be difficult because there are so many ways to build a website. Our understanding of this space is informed by our work in Chrome talking to large sites over the past f
Next.jsアプリケーションの開発時においてコンパイルが長時間に及ぶ問題が起きていたので、その原因を特定した手法と採用した解決策について記載します。 今回は結果的にコンパイル時間を100倍以上高速化することができました。 前提 今回の対応は以下のバージョンで行いました。 React@18.2.0 next@12.2.4 tailwindcss@3.2.4 postcss@8.4.14 Next.js の開発中に、コンパイル時間が長くなっていることに気づく 最近、Next.jsアプリケーションのローカル開発時に待ち時間が長くて生産性が低いのでなんとかしたい、という相談を受け、調査を開始しました。 まず、おもむろにyarn devでプロセスを立ち上げてみたところ、以下のようなコンパイル時間を示すログが表示されました。 yarn dev yarn run v1.22.19 $ next dev
「Web Speed Hackathon 2022」という「非常に重たいWebアプリをチューニングして、いかに高速にするかを競う競技」があります。 リモート参加で11月1日から27日まで開催されています。 ここで言う「高速」とはCore Web Vitalsのスコアが高いことを言い、Lighthouseのスコアをベースにした500点満点の争いです。 ISUCONのフロントエンド版ですね。 以前にも同じ課題で「学生向け」と「社内(サイバーエージェント)向け」が行われたらしく、まだ500点を出した人はいません。 そこで僕は「満点を出したい」と思い、初日から、いやむしろフライングしていたからその前から頑張ってきました。 そして、先日(17日)、ついに500点満点を出しました! たぶん、レギュレーションはクリアしている、はずです(もし違反してたらすいません…)。 自動で行われる「Visual Re
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、第11代黒帯(ヤフー内のスキル任命制度/Webフロントエンド領域)の浜田(@narirow)です。今回はヤフー全社で実施してきた、「Webパフォーマンス改善プロジェクト」についてお話ししたいと思います。 長期に渡る活動の結果、多くのサービスのWebパフォーマンスが徐々に向上しています。この記事では、取り組みの経緯や、多くのサービス分析を通してわかったコスパの良い施策(比較的簡単に実施できてスコアも上がりやすい施策)などをご紹介します。 全社横断でWebパフォーマンス改善を実施する経緯 さかのぼること2021年、Googleから以下のような案内がありました。 「Core Web VitalsがGoogle検索の検索順位に
すでに知られているように、Webページの表示速度は重要です。利用者はいつでもどこでも素早くページが表示されて欲しいと思うでしょう。Core Web Vitalsの指標でも表されているように、表示速度は一時的に速いだけでなく、安定していることが求められます。 本記事では、安定した表示速度を実現する手段の一つとして考えられるPrerenderingをオリジン・トライアルで試してみた結果をご紹介します。 Prerenderingとは Prerendering実装前に注意すること Quicklinkを使ったPrerenderingの実装 Prerenderingのヒット率を計算する Prerenderingの結果 Prerenderingとは Prerenderingは次に表示されると思われるページを事前にレンダリングします。レンダリングが完了している場合には、利用者がそのページに遷移するリンクを
皆さんこんにちは。現在、フロントエンドでは宣言的UIが大流行しており、そのためのライブラリもReactを筆頭に複数存在しています。 ライブラリが複数存在するところには当然のように比較や論争が起こるものですが、UIライブラリの場合はパフォーマンスがよく焦点となります。 筆者はReactの信者ですが、Reactは古株ということもあってか、最近の議論ではReactは他のライブラリと比較されるかませ犬のような役割を担うのがよく見られます。「仮想DOMは必要ない」といった類のものです。 しかし、筆者の考えではReactは今でも、もっとも真剣にパフォーマンスに取り組んでいるUIライブラリです。特に、Reactはパフォーマンスを高いユーザーエクスペリエンスのための手段として捉えており、ドキュメントにもユーザーエクスペリエンスという言葉が多く出てきます。 そこで、今回はReactが最も有利になるようなベン
達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践 作者:藤原 俊一郎,馬場 俊彰,中西 建登,長野 雅広,金子 達哉,草野 翔技術評論社Amazon 著者のid:catatsuyさんよりご恵投いただきました。ありがとうございます。実は著者の方から本を頂戴するのってはじめてです。 さて、この書籍のタイトルをはじめて見たときは「オッ、ついにISUCONの攻略本が来ましたね、これでワシも優勝間違いなしや!!」と思ったものですが実際に手に取ってみると必ずしもそうではないことに気付きました。むしろ「ISUCONで勝つための小手先のテクニック」のような話題は極力排除されており、高速かつ高可用なWebアプリケーションをどのように構築・運用していくか、というような実戦的な内容がその多くを占めています。 まず書籍の冒頭では「『Webアプリケーションのパフォーマンス』の定義」か
「達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践」という本を6名の共著で執筆しました。技術評論社さんから、2022年6月4日発売予定です。電子版もでます。 gihyo.jp Amazon はこちら。 達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践 作者:藤原 俊一郎,馬場 俊彰,中西 建登,長野 雅広,金子 達哉,草野 翔技術評論社Amazon タイトルの通り、ISUCON で出題されるようなWebサービスを例にして、Webサービスのサーバーサイドパフォーマンスチューニングを指南する内容です。通称「ISUCON本」と呼んでください。 2020年の末に、技術評論社さんからWebサービス高速化 × ISUCONに関する書籍を執筆しませんか、と藤原までお誘いをいただいたのが発端でした。 書きたい気持ちはあったものの、内容的にとて
State Colocation will make your React app fasterSeptember 23rd, 2019 — 11 min read One of the leading causes to slow React applications is global state, especially the rapidly changing variety. Allow me to illustrate my point with a super contrived example, then I'll give you a slightly more realistic example so you can determine how it can be more practically applicable in your own app. Here's th
皆さんこんにちは。筆者の以前の記事では、ReactのuseMemoを無駄に使うことによるレンダリング速度のオーバーヘッドがどれくらいかをベンチマークによって示しました。 それによれば、スマートフォンを想定したとしても、useMemoだけで描画に目に見える影響を与える(16msくらいの遅延を発生させる)には万のオーダーのuseMemoが必要なことが分かります。 速度ではなくuseMemoを使うことによるメモリ消費量の増加を気にする声も聞かれましたが、すみませんが筆者はそこまでメモリクリティカルなアプリをReactで書いたことがなく知見に乏しいため、今回はこの記事の対象外となります。 この結果が出たことでuseMemoをいつ使うのかなどという議論には終止符が打たれたかと思いきや、上記の記事の感想などを見ているとまだ喧々囂々です。 そこで、この記事では筆者の考えを皆さんに共有し、いよいよもってこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く