これまでフロントエンドのビルドにはWebpackを使ってきましたが、Web上で動作するReactアプリを制作するにあたり、初めてViteを採用しました。
実際に使って感じたWebpackとの違いと、ビルドしたファイルをレンタルサーバーへ配置する手順をまとめます。
プロジェクトの要件
今回の制作物は以下の要件でした。
- CMSを使わず、React製のSPA（Single Page Application）を静的ファイルとして配信する
- コンテンツはJSONデータと画像が中心
- クライアント側ルーティングは使わない（単一ページ構成）
- レンタルサーバーにFTPで配置する
- SEOは考慮不要（Webアプリケーション用途）
環境構築の時間を短縮するため、設定の少ないViteを採用しました。
SEOについての注意：
SPAはJavaScriptでコンテンツを動的に生成するため、検索エンジンのクローラーに適切にインデックスされない場合があります。SEOを重視するサイト（コーポレートサイト、ブログ、ECサイトなど）を作る場合は、Next.jsやRemixなどSSR（Server Side Rendering）やSSG（Static Site Generation）に対応したフレームワークを検討してください。
体感で一番違ったのは「待ち時間」
Webpackと比較して大きく違ったのは、開発中の待ち時間と初期設定の少なさです。
- 開発サーバーの起動が速い
- ファイル変更後の反映が速い（WebpackにもHMRはありますが、Viteの方が軽量で高速です）
- デフォルトでJSX変換が動作する（追加のBabel設定が不要）
- ローダーの明示的な設定が不要
開発中の待ち時間が減ることで、作業が途切れにくくなり、制作効率が上がりました。
WebpackとViteの実用上の違い
両者は開発時のモジュール読み込み方式が異なります。
Webpack
すべてのモジュールをバンドルしてから動かす設計です。開発環境でもバンドル処理の影響を受けやすく、プロジェクトが大きくなると起動やHMRが遅くなりがちです。
Vite
開発時はブラウザのネイティブESM（ES Modules）を利用し、必要なモジュールだけを直接読み込みます。本番ビルド時はRollupでバンドルと最適化を行います（将来的にはRolldownへの移行も予定されています）。
この仕組みの違いにより、Viteは開発中の動作が軽快です。
ブラウザ対応の注意：
ViteはネイティブESMを使用するため、IE11には対応していません。モダンブラウザ（Chrome、Firefox、Safari、Edgeの最新版）が前提となります。
今回使った環境
{
"dependencies": {
"react": "^18.2.0",
"react-dom": "^18.2.0"
},
"devDependencies": {
"vite": "^5.0.0",
"@vitejs/plugin-react": "^4.2.0"
}
}開発サーバー起動：
npm run dev本番ビルド：
npm run buildvite.config.js の設定
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
export default defineConfig({
plugins: [react()],
build: {
outDir: 'dist',
assetsDir: 'assets',
emptyOutDir: true // デフォルトでtrueだが、意図を明示
}
});各設定の意図
@vitejs/plugin-react
公式のReactプラグインを追加するだけでJSX変換が動作します。内部でesbuildを使用しているため高速です。Babel特有の機能（decoratorsなど）を使う場合は追加設定が必要ですが、標準的な構成であれば不要です。
outDir: 'dist'
ビルド結果の出力先ディレクトリを指定します。デフォルト値も dist ですが、設定ファイル上で明示しています。
assetsDir: 'assets'
生成されたJS、CSS、画像ファイルを assets/ 配下にまとめます。出力構造が整理されるため、FTPアップロード時の管理がしやすくなります。
emptyOutDir: true
ビルド前に出力先ディレクトリを空にします（デフォルトで有効ですが明示しています）。古いビルド結果が残らないため、不要なファイルを誤ってサーバーへアップロードするミスを防げます。
画像の扱い
画像は用途に応じて2通りの方法で配置しました。
- 動的にimportする画像：JSX内で
importして使用 - 静的に配信する画像：
public/ディレクトリに配置
public/ 内のファイルはビルド後も同じパスで参照できるため、JSONデータ内で画像パスを管理する場合に適しています。
レンタルサーバーへの配置
ビルド後に dist/ へ生成されたファイルを、そのままレンタルサーバーにアップロードします。
手順
npm run buildでビルドを実行する- FTPクライアント（FileZillaなど）でサーバーに接続する
dist/の中身を/public_html/にアップロードする
注意：
公開ディレクトリの名称はサーバーによって異なります。/public_html/、/htdocs/、/www/ など、利用しているサーバーの仕様を確認してください。
サブディレクトリに配置する場合
/app/ のようなサブディレクトリに配置する場合は、vite.config.js に base オプションを追加します。
export default defineConfig({
base: '/app/',
// ...
});今回はドメイン直下で配信するため、base は指定していません（未指定時は自動的に / になります）。
この構成で困らなかった理由
ルーティング不要
単一ページ構成だったため、React Routerなどのクライアント側ルーティングは使用していません。ルーティングを使う場合は、すべてのリクエストを index.html へ内部的にリライトする .htaccess 設定がサーバー側で必要になります。
プラグイン1つで完結
@vitejs/plugin-react を導入するだけで、JSX変換からHMRまで一通り動作しました。
dist出力＋FTPアップロード
サーバー側での特別な設定は不要で、dist/ の中身をアップロードするだけで公開できました。
Webpackの方が向いているケースもある
以下のようなケースでは、無理にViteへ移行せずWebpackを使い続ける方が合理的です。
- 既存案件がWebpack前提で構築されている
- 独自のローダーやプラグイン資産が多い
- ビルド要件が複雑で、細かいカスタマイズが必要
まとめ
- 小〜中規模のReact SPAであれば、Viteで手早く開発を始められる
- レンタルサーバーへはビルド後の
distの中身を配置するだけで公開できる - 初期設定の手間が少なく、開発サーバーの起動や反映が速い
- モダンブラウザ前提の構成である点には注意が必要
- SEOが重要なサイトには向かない（SSR/SSG対応フレームワークを検討すべき）
同様の単一ページ構成のReactアプリでは、今後もViteを第一候補として採用する予定です。
