この記事は[FOLIO Advent Calendar 2018](https://adventar.org/calendars/3424) 12日目の記事です。 --- これまで2年ほどお世話になったはてなブログから乗り換えて、この度個人ブログを新調しました。 [https://blog.andoshin11.me/](https://blog.andoshin11.me/) Nuxt + Contentfulという構成のPWA対応アプリケーションをGAEにホストしています。プロダクションで回遊するとこんな感じ。 ![Studio Andy](https://gyazo.com/04d4ed7f3ced61995420d368761007b1.gif) 我ながらヌルサクなWebサイトになったかと思います。せっかくモダンな設計に作り直してPWA対応も行うということで、 **「Lighthouse Performance Scoreで阿部寛のHPを超える！」** という事を一つのベンチマークにパフォーマンスチューニングに挑みました。今回はその結果と、開発時に行った内容のサマリーをご紹介します。また、本ブログの[ソースコード](https://github.com/andoshin11/studio-andy)はPublicな状態で公開しています。要望・問題等ありましたら気軽にIssueやPRをお待ちしています。 Embedded content: https://github.com/andoshin11/studio-andy ## Lighthouse Score まずはこれを見てくれ！！ ![阿部寛さんのHP](//images.ctfassets.net/2p1otbbee5vt/1U3Wyu63x2S0W2sQ6EKE68/73b8abb5db52a4b3fbcd96ee1ebf9ff4/____________________________2018-12-11_1.18.50.png) ![スクリーンショット 2018-12-11 1.29.51](//images.ctfassets.net/2p1otbbee5vt/18oyB4DjSKG6IQscSeSGGo/8d35dead5934b2abe8f4f758baa9bee8/____________________________2018-12-11_1.29.51.png) どちらもPerformance Scoreは100点！そして[First Contentful Paint](https://developers.google.com/web/tools/lighthouse/audits/first-contentful-paint)では僕のサイトの方が1/2という結果に！勝った！！阿部寛に勝利したぞ！！！！！！ ### 実測値せっかくなので本ブログと他のいくつかのウェブサイトもLighthouseで比較してみましょう。計測環境は以下の通りです。 ``` - 端末　MacBook Pro (Retina, 15-inch, Mid 2015) - プロセッサ 2.5 GHz Intel Core i7 - メモリ 16 GB 1600 MHz DDR3 - Chrome 70.0.3538.110（Official Build）（64 ビット） Incognito Mode ``` まずはキャッシュをオフにした状態の計測から

対象サイト	Performance	PWA	A11y	Best Practice	SEO	FCP	FMP
本サイト	99	100	100	100	100	980ms	980ms
阿部寛HP	100	31	18	80	67	900ms	900ms
日経電子版	27	19	58	73	82	3240ms	3310ms
dev.to	87	96	86	93	91	940ms	990ms
旧サイト(はてなブログ)	26	12	61	60	91	1560ms	1640ms

次にキャッシュをオンにした状態

対象サイト	Performance	PWA	A11y	Best Practice	SEO	FCP	FMP
本サイト	100	100	100	100	100	10ms	30ms
阿部寛HP	100	31	18	80	67	20ms	20ms
日経電子版	79	46	58	73	82	1960ms	1980ms
dev.to	97	96	86	93	91	780ms	850ms
旧サイト(はてなブログ)	34	12	61	53	91	1530ms	1530ms

旧サイト(はてなブログ)からのパフォーマンスの伸びが顕著ですね。 Performanceは言わずもがなですが、はてなブログでPWA対応がほとんどされていないのが気になりました。Service Workerのような標準化しつつある仕様に追従できていないのは痛いところ。 ## Nuxt + Contentfulでやっていき今回の実装にあたってはフレームワークに依存せずSPAを作成することも検討しましたが、SEOなどを考えるとSSRの仕組みが必須です。またSSRもスクラッチで組もうとすると中々ハードルが高く(Storeのハイドレーション、Render hooksのAPI設計等)、今回は業務でも利用した事のあるNuxt.jsを利用しました。 Embedded content: https://nuxtjs.org/ 詳細は後述しますが、Nuxt communityの提供しているModule群がものすごく使い心地が良く、おかげで爆速で開発を進めることができました。また、Clean Architecture大好きマンとしてフレームワークにロックインされるリスクも考慮したのですが、Nuxt独自の仕組みもそこまで多くはなく(Routerの設定くらい？)将来別のフレームワークにコードベースの大部分を移植できそうだという判断で採用に至りました。 Embedded content: https://www.contentful.com/ ブログコンテンツをホストするヘッドレスCMSには最近人気上昇中の[Contentful](https://www.contentful.com/)を利用しています。 N to Nのリファレンスタグを実装する際などは少し難がありそうですが、全文検索クエリを発行してもレスポンスが非常に良く、APIも必要十分なものが提供されていたためお試し的に採用。 Content Modelのschemaをgenericsで渡せるようになっており、TypeScriptとの相性も良さそうです。 ## 開発パート ### TypeScript開発環境の設定昨日公開した[こちら](https://blog.andoshin11.me/posts/nuxt-with-typescript)の記事にて。 Embedded content: https://blog.andoshin11.me/posts/nuxt-with-typescript ### アーキテクチャ今回もClean Architecutre **風味**な設計を採用。透過性の高い `Use Case`レイヤーを中心に、各種Adapterを設計しています。ステート管理には[Vuex](https://github.com/vuejs/vuex)を利用していますが、 `mutations`を通した各プロパティのCRUD以外は行わないObservable Dumb State Boxとして使うのが僕は好きです。 `actions`も使いません。 ### CI/CD GitHub上の `master`ブランチに変更が加えられたタイミングで[Circle CI Workflow](https://circleci.com/)をトリガーし、CI上からGAEにデプロイを行っています。サービスアカウントの作成方法やインスタンスの設定方法はネットにたくさん資料があるので割愛。気になる方は `.circleci/config.yaml`や `app.yaml`あたりを参考にどうぞ。 SentryへのSourcemapのアップロードもこちらで行っています。 ## Performance対策ここからが今回の本題であるパフォーマンスチューニング編です。 ### WebPの利用旧ブログから移行した記事はともかく、新しい記事内や一覧ページでは要所に[WebP](https://ja.wikipedia.org/wiki/WebP)を利用しています。 WebPは画像ファイルの圧縮効率がPNGよりも優れているだけでなく、デコード時のパフォーマンスにも分があるため、最新のブラウザで高速にWebページを表示する際には対応必須と言えるフォーマットでしょう。圧縮作業は `$ brew install webp`でコマンドをインストールした後にCLIで ```shell $ cwebp hoge.png -o hoge.webp -q 50 ``` を実行して手動で行ってます(効率化したい)。圧縮時に指定するクオリティは画像ごとにチューニングの余地がありそうですが、雑に50付近を指定。ブラウザでの描画時は `