Vue Fes Japan 2024 セッションレポート「Vue3の一歩踏み込んだパフォーマンスチューニング 2024」の紹介と所感 - giftee Tech Blog

giftee Tech Blog

ギフティの開発を支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信しています。

Vue Fes Japan 2024 セッションレポート「Vue3の一歩踏み込んだパフォーマンスチューニング 2024」の紹介と所感

eye_cache

こんにちは、エンジニアの toki (@tokai235) です。法人向け eGift サービス giftee for Business の開発をしています。普段はバックエンドやインフラのお仕事が多いですが、フロントエンドエンジニアを自称しています。

先日開催された Vue Fes Japan 2024 に参加してきまして、色々と面白いセッションやパーティを楽しんできました! 会場でお話いただいたみなさま、ギフティブースに立ち寄っていただいたみなさま、ありがとうございました!

その中でも印象に残ったセッションがあったので、自分の所感も交えながらご紹介できればと思います。

セッション 「Vue3 の一歩踏み込んだパフォーマンスチューニング 2024」 について

お話したいセッションは Hal さんによる 「Vue3 の一歩踏み込んだパフォーマンスチューニング 2024」 です。

パフォーマンスチューニングといえば SQL やバックエンド改善の文脈で語られることが多いですが、このセッションでは Vue 2,3 にフォーカスした内容になっています。

セッションでは Hal さんのチームやプロダクトで今回ぶつかったパフォーマンス課題について説明いただきつつ、Vue 2,3 で実際にできるパフォーマンス改善について、コードを交えて紹介いただきました。

ここではそのいくつかをご紹介できればと思います。

パフォーマンスチューニング Tip

無駄な更新をしない

Vue.js では v-model という双方向バインディングが簡単に実装できるディレクティブがあります。

これは非常に便利な機能ですが、v-model の値が変更されるたびに発火されるため、更新処理が非常に重い場合、何度も重い更新処理が走ることになり、パフォーマンスが悪くなってしまいます。

もちろんこれが毎回必要な処理であるならば、処理そのものを軽量化する必要がありますが、毎回必要な処理でない場合、更新頻度を減らすというアプローチを取ることができます。セッションで紹介されていた例としては、Blur (入力フォームからフォーカスが外れた)時のみ更新処理を発火する、debounce する、v-memo を使うなどがありました。

debounce は一定期間内に何度も関数が発火するのを抑えるプログラミング手法です。実装は非常にシンプルで、自前でも容易に実装できます。

ref: What is Debouncing?

function debounce(func, interval) {
  let timer

  // ↓ の setTimeout でセットしたタイマーをクリアする
  clearTimeout(timer)

  // interval 秒後に関数を call するタイマーを仕込む
  // interval 秒内に ↑ でclearTimeout されなければ予定通り関数が call される
  return function (...args) {
    timer = setTimeout(() => {
      func.apply(this, args)
    }, interval)
  }
}

なお Vue3 の Composition API には defineAsyncComponent が用意されており、自前で実装することなく debounce を実現できるとのことです。

Vue 3.5 を使う

2024/09 にリリースされた Vue 3.5 では、大幅な高速化とメモリの効率化が図られています。メモリ使用量はこれまでと比べ 56% 減となっており、パフォーマンスも数倍速くなっているとのことです。

こういったフレームワークや言語自体のパフォーマンス改善は非常に恩恵が大きいので、大変でもアップデートしていきたいですね。

セッションを聞いて思ったこと

フロントエンドアプリケーション開発者の視点でのパフォーマンスチューニングのトークテーマは珍しいなと思ったのでご紹介しましたが、各フレームワークの開発の方向性としては「高速化・高効率化」は今非常にアツいトレンドかなと思います。

Vue に限らず、Single Page Application (SPA) 一辺倒だったところに React が Server Side Rendering を発表して以降、Next.js も同様の機能をリリースし、フロントエンドでは流れとして「分割して小さくレンダリングする」方向に進んでいると感じています。

これはモダンな Javascript ライブラリ / フレームワークの恩恵により、現代の Web フロントアプリケーションが巨大で複雑になってきたところで、パフォーマンスの問題が無視できないほど大きくなってきたということなのかなと思っています。

個人的にはまた 1 つ Web フロントエンドの転換期が訪れている気がしていますが、よく考えるとフロントエンド界隈は常に転換期な気がしなくもないので、振り落とされないようにやっていきたいと思います。

ギフティではフロントエンドエンジニアを募集しています。ぜひカジュアル面談などでお話ししましょう。

We Are Hiring!