Apollo Client と SSR の罠 その1 - パフォーマンス改善編 | Wantedly Engineer Blog
Wantedly でバックエンドエンジニアをしている @izumin5210 です。 この記事は GraphQL Advent Calendar 2020 の11日目の記事として書かれました。が、7割くらいは SSR についての議論のこり3割くらいが Apollo Client の話です。 最近、Apollo Client と SSR(Server Side Rendering) を利用した Web アプリケーションのパフォーマンス改善に取り組みました。この記事では「パフォーマンスの問題にどう立ち向かったか」および「そもそも問題を起こさない構造にするために何ができるか・何をすべきでないか」の考察をしていきます。 TL;DRパフォーマンス改善は計測・可視化からライブラリが用意してくれているフック機構を上手に使って計測していこうrenderToStringWithData では、renderT
Netflix がReact をやめて、SSRにしたらランディングページを 50% 高速化できたということらしいのですが、一方slackはReactで高速にしたとのことですが、この違いは何でしょうか？
Before You memo() — overreacted
There are many articles written about React performance optimizations. In general, if some state update is slow, you need to: Verify you’re running a production build. (Development builds are intentionally slower, in extreme cases even by an order of magnitude.) Verify that you didn’t put the state higher in the tree than necessary. (For example, putting input state in a centralized store might no
useCallbackはとにかく使え！ 特にカスタムフックでは - uhyo/blog
Reactには、パフォーマンス最適化のためのAPIがいくつかあります。具体的にはReact.memo、useMemo、そしてuseCallbackです。 React.memoで囲まれた関数コンポーネントは、propsが以前と変わっていない場合に再レンダリングが抑制されます。 また、useMemoやuseCallbackは、関数コンポーネント内での値の再計算を抑制する効果を持ちます。 これらは最適化のためのツールなので、「過度な最適化」を避けるように啓蒙する言説がよく見られます。 すなわち、ちゃんと本当に最適化のために必要なところにだけこれらを使おうということです。 特に、React.memoはpropsが以前と変わっているかどうかを判定するためのオーバーヘッドがあるし、useMemoやuseCallbackもフック呼び出しのオーバーヘッドがあります。 意味がないところでReact.memo
【LINE証券 Frontend】requestIdleCallbackを活用して初期レンダリング時間を約14%削減した話
こんにちは。フィナンシャル開発センターの鈴木です。LINE証券のフロントエンドを担当しています。この記事は【LINE証券 FrontEnd】シリーズの4番目の記事です。 最近のWeb Vitalsの隆盛を受けて、LINE証券のフロントエンドでもパフォーマンスの改善に取り組み始めました。およそ2週間ほど改善に取り組んだ結果として、開発環境での計測ではLighthouseのperformanceスコアが従来より30点ほど上昇しました。 パフォーマンス改善のためにさまざまな施策を行いましたが、この記事ではその中でも興味深かったものとして、requestIdleCallbackを活用してLazy Loadingされるコンポーネントの読み込みを遅延し、その結果初期レンダリングにかかる時間を約14%削減できた事例をご紹介します。 環境 以前の記事でご紹介したとおり、LINE証券のフロントエンドはTyp
React Server Components 総まとめ
先日、React Server Componentsについてまとめる機会がありました。 この記事では、React Server Componentsの概要と、デモを触る中で感じたことについてご紹介します。 React Server Componentsとは React Server Componentsは、Reactコンポーネントをサーバーサイドでレンダーする新しい技術です。 一部のコンポーネントをサーバーサイドでレンダーしてしまうことで、アプリケーションのパフォーマンスを上げることを目的とします。 図は、デモの画面のうち、サーバーでレンダーされる部分を青で、クライアントでレンダーされる部分を赤で示したものです。 ページ全体をサーバーでレンダーするのではなく、一部のコンポーネントはクライアントにレンダーさせていることがわかります。 また、React Server ComponentsはCo
You Need to know SSR - Speaker Deck
ng-japan で発表した Server Side Rendering の資料です。
Reactでレンダリング回数やレンダリングにかかる時間をユニットテストでテストできるライブラリを開発しました - Qiita
import React from 'react'; import { render, fireEvent, screen } from '@testing-library/react'; import { perf, wait } from 'react-performance-testing'; test('countボタンをクリックした時に、2回レンダリングする', async () => { const Button = ({ name, onClick }) => ( <button type="button" onClick={onClick}>{name}</button> ); const Counter = () => { const [count, setCount] = React.useState(0); return ( <div> <span>{count}</
React17におけるuseEffectの破壊的変更を理解する
しばらく前、React 17 RCが発表されました。現行のReact 16に比べて、いくつかの破壊的変更がある一方、新機能が何もないというのが特徴です。Reactチームとしては、新機能が無いとはいえ、破壊的変更も少なくなっておりなるべく16から17へのアップデートを行なってほしいという考えのようです。 この記事では、React 17における破壊的変更のうち、useEffectのクリーンアップのタイミングに関する変更を取り上げます（以下は公式サイトから引用）。 In React 17, the effect cleanup function also runs asynchronously — for example, if the component is unmounting, the cleanup will run after the screen has been updated.
React Fiber現状確認
F8でもReact Fiberについての発表もあったので、気になっている人も多いReact Fiberの現状について簡単に書きたいと思います。 Reactの完全な書き換えということで、使い方も変わってしまうと思っている人もいると思いますが、内部実装の書き換えであり、利用者から見える部分ではほとんど変更はありません。 もちろん、react-fiberというパッケージをインストールするというわけでもありません。 むしろ、v16の時点では現在の実装と互換性を保たれているので、v16がリリースされた時に、v15.5を使っていればほとんどそのままv16に更新できると思います。 そして、言われなければ内部実装が変わっていることに気づかないのではないかと思います。 とりあえずどうなるのか知りたい人向けのまとめ v16では、基本的にはv15の時と同じように動作します。逆に言うとパフォーマンスもそんなに変わ
パフォーマンス最適化 – React
この記事は古くなっており、今後更新されません。新しい React 日本語ドキュメントである ja.react.dev をご利用ください。 以下の新しいドキュメントで最新の React の使い方が学べます。 memo: props が変更されていない場合に再レンダーをスキップする React は UI の更新時に必要となる高コストな DOM 操作の回数を最小化するために、内部的にいくつかの賢いテクニックを使用しています。多くのアプリケーションでは React を使用するだけで、パフォーマンス向上のための特別な最適化を苦労して行わなくても、レスポンスの良いユーザインターフェースを実現できますが、それでもなお、React アプリケーションを高速化するための方法はいくつか存在します。 本番用ビルドを使用する React アプリケーションでベンチマークを行う場合やパフォーマンスの問題が発生している場
Using the React DevTools Profiler to Diagnose React App Performance Issues
The latest version of the React DevTools (released on Aug 23) offers a powerful new tool to detect and diagnose performance issues in your React app: the new Profiler tab! This post describes how we recently used the Profiler to quickly diagnose and fix a known and long-standing performance issue in the clientside display of our server logs on app.netlify.com. Problem Statement Whenever you trigge
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
