Laravel+Vue.jsでSPA(シングルページアプリケーション)を作成した

今回作成したサイト 今回作成したサイトは以下のサイト。 ClubPage 私が所属している電子工作サークルのホームページを作った。 このブログからcssを流用しているので、見た目がだいぶ似ている。 構成 Laravel Vue.js バックエンドはLaravel、フロントエンドはVue.jsを使っている。 シングルページアプリケーションとは 今回はシングルページアプリケーション(SPA)という構成を採用した。 シングルページアプリケーションとは シングルページアプリケーション(英: single-page application、SPA)とは、単一のWebページのみから構成することで、デスクトップアプリケーションのようなユーザ体験を提供するWebアプリケーションまたはWebサイトである。必要なコード(HTML、JavaScript、CSS)は最初にまとめて読み込むか[1]、ユーザの操作などに応じて動的にサーバと通信し、必要なものだけ読み込みを行う。 Wikipediaより というものらしい。 これまでRuby on RailsやDjangoとかを使ってwebサイトを作ってみてきたが、どれも各ページ毎に、サーバ側でHTMLの生成を行うマルチページアプリケーションだった。 今回はLaravelでwebAPIを作成し、そのAPIから取得した情報を、Vue.jsを使ってブラウザ上に表示するような構成にした。 なぜSPAにしたのか 理由は1つで、今回参考にしたサイトがSPAを採用していたから。 今回参考にしたサイトは以下のサイト。 このサイトにあるチュートリアル、書かれている情報量がかなり多くて、これだけの情報をタダで得られるのが信じられない。 今回初めてLaravelとVue.jsを触ったが、このサイトのおかげで色々と基礎を学ぶことができた。 今回学んだこと、感じたこと インタフェース部とエンジン部の分離はやはり重要 今回の構成はAPI(Laravel)と表示部(Vue.js)を分離している。 たとえばhttps://home.lchika.club/api/tagsにアクセスすれば、Laravelの機能によって、タグの一覧をJSON形式で取得できる。 こういったAPIから取得した情報をVue.jsで処理して、ブラウザにレンダリングする。 このように分離することで、UIを変えたいときは、基本的にVue.jsの部分のみを修正するだけですむ。 Laravelの処理部は一切手を加える必要がない。 まあ、一般的なwebフレームワークを使っていれば、実装の分離は適切に行われているが、ある一部分のフレームワークをごっそり切り替えることはできない。 今回の構成では、例えばフロントエンドにReactを使いたければ、Laravel部分はそのままで、フロントエンド部分をごっそり切り替えられる(と思うけど、Laravel-mixとかの関係で難しいのかもしれない…)。 このように、インタフェースとエンジン部の分離で得られる効果はやはりでかいなと思った。 ローディング表示がないとwebサイトの質が落ちる これは個人的な印象かもしれないが、ローディング画面の表示はユーザにとって(ある程度)重要だなと思った。 現状ではローディング表示は実装していないため、読み込み直後は一部のコンテンツが表示されていないし、一部のコンテンツについては結構な時間表示されないことがある。 これはサイト利用者側からすると、違和感を覚える要因になり、満足度の低下につながると思った。 YouTubeとかもローディング中はコンテンツ表示部をグレーで表示したりしている。 最初はこれ意味あるのか?と思っていたが、今回自分でJavaScriptを多用したサイトを構築してみて、こういった対応も重要だなと思った。 WYSIWYGエディタの選定は毎回の課題 今回はブログのようなサイトを構築したので、フォームから記事を投稿できる必要があった。 さすがにHTML直打ちで入力はできないし、リッチテキストエディタを採用する必要があった。 毎回どのリッチテキストエディタを使うか苦労するが、今回も例に漏れず苦労した。 とりあえず今のところはCKEditorを使っている。 ただ、まだ課題があって、iframeの挿入が上手くいっていない。 いつも大体、リッチテキストエディタまわりは 画像の挿入 画像の整形 外部コンテンツの挿入 目次の作成 あたりで詰まっている。 今回はまだ目次の作成について考えていないので、目次が必要になった時に多分また詰まる。 SPAのパフォーマンス向上はバンドルサイズの削減こそ正義 今回作成したサイトのパフォーマンス向上については以下の記事に書いた。 最初特に何も考えずにサイトを作っていたら、パフォーマンスが崩壊した。 今もパフォーマンスが良いとは言えないが、バンドルサイズを削減することで、パフォーマンスが向上した。 こういったパフォーマンス向上のための施策は必要不可欠だなと感じた。 まとめ 今回はLaravelとVue.jsを使ってサイトを作った。...

March 15, 2020 · 1 min

Laravel+Vue.jsでLighthouseのスコアを0点から97点にした(バンドルサイズ削減)

Laravel+Vue.jsで作成していたwebサイトの応答速度が激遅だったので、対策を実施した。 環境 Laravel 6.14.0 Vue.js 2.6.11 対策前はページロードに20秒かかっていた 特に何も考えずにwebサイトを作っていたら、トップページのロードに20秒ほどかかっていた。 これではさすがにwebサイトとして成立しない。 Googleが提供しているwebページ分析ツールLighthouseを使ってパフォーマンスの測定を行ったところ、以下のような結果になった。 堂々の0点である。提示されている対応策の詳細を見ると、以下のように書かれていた。 どうやらバンドル後のapp.jsのサイズが約4MBと、超巨大になっているらしい。対応策としてapp.jsのサイズ削減を行った。 対策1:本番用ビルド設定を適用する バンドルサイズ 3.86MB(app.js) → 1.59MB(app.js) 解説 そもそもビルド設定が間違っていた…。ビルドコマンドとして npm run dev を実行していたが、これは開発用のビルドコマンドらしい。 本番用のビルドコマンド npm run prod を実行したところ、バンドルサイズは3.86MB→1.59MBと、約40%になった。 Lighthouseの結果 0点→10点に上昇した。 対策2:gzipで圧縮する バンドルサイズ 1.59MB(app.js) → 395KB(app.js.gz) 解説 以下のページを参考に、gzipでapp.jsを圧縮した。 そのままコピペで適用できた。 Lighthouseの結果 10点→63点に上昇した。 対策3:ページごとにJSファイルを分割する バンドルサイズ 395KB(app.js.gz) → 243KB(app.js.gz) 解説 以下のページを参考に、ページごとにJSファイルを分割した。 こちらも特に詰まることはなく、ほぼコピペで実装できた。 この対策を実装したことで、ビルド後のJSファイルが以下のように、分割されて生成されるようになった。 Lighthouseの結果 63点→87点に上昇した。 対策4:bootstrap-vueの選択的インポート バンドルサイズ 243KB(app.js.gz) → 129KB(app.js.gz) 解説 対策1~3で、あらかた大きなところは対策できたと思ったので、より細かいところを対応するため、webpack-bundle-analyzerを使ってバンドル結果の分析をした。 webpack-bundle-analyzerの出力結果は以下のようになった。 この結果から bootstrap-vue ckeditor lodash あたりのサイズが大きいらしいことが分かった。...

March 8, 2020 · 1 min