スピーカー自己紹介、『JavaScript コードレシピ集』を出版
池田泰延 氏(以下、池田):みなさんよろしくお願いします。ICSの話として、私と鹿野の2名で発表します。HTMLとかCSSとかJavaScriptとか、フロントエンドまわりの最新を説明していきたいと思います。では始めていきましょう!
ます自己紹介します。ICSの池田と言います。株式会社ICSの代表をやっています。これはオフィスの写真でして、南麻布にあるのですが、こんなところで仕事をやっています。今はこの状況下なので、会社にはほとんど誰も行っていませんが、こんなところでやっていました。
JavaScriptに関して2年ほど前に『JavaScript コードレシピ集』という本を出しています。この本はまだ役に立つ内容もあるかなと思いますので、もし書店で見かけましたらぜひご購入を検討ください。宣伝でした。
Webの劇的な変化は少なくなってきた
次は、今回の話のいきなり結論から話そうと思います。フロントエンド2020という話なんですが、Webの劇的な変化は少なくなってきたと思っています。(私は)今は制作フローと品質を改善するフェーズにたどり着いたと見ています。私から今日はこれについて、20分話そうと思いますが、なぜこういう結論に至ったのかということを振り返りながら説明していきたいと思います。
今日は「フロントエンドの技術の変遷」ということで、少し歴史を振り返ってみたいと思います。昔はフロントエンド技術というのは移り変わりが激しいということがよく言われていました。確かにそれはあったかなと思います。JSライブラリとかを少し遡ってみると、2010年の頭ぐらいからAngularJSとかBackboneとかKnockoutとか、こういうライブラリが非常に出てきていました。
ただ最近は3大フレームワークと言われていますが、Angular、Vue、Reactというところが主流になっているかなというところで、いろいろ筍のようにたくさん出てきていたツールも、ある程度集約されてきたのかなという印象があります。
これはnpm trendsという、パッケージモジュールのダウンロード数の推移を比較したものですが、この黄色で伸びているところがReactなんです。VueとAngularもそれぞれ伸びていますね。これは全世界で見た数値で、あとはライブラリの構成によってダウンロード数も変わりますが、大まかな傾向としてずっと右肩上がりに上がっているというような状況がわかります。
webpackが一強になっている
ビルドシステムについてもこれも変化がありまして、昔だったら2013年ぐらいにGruntと呼ばれるツールがパラダイムシフトのように出てきたわけです。
だけど、今はGruntを使っている人はあまりいなくて、Gulpに移り変わっていたりしています。他にもJavaScriptのほうだと、BrowserifyとかAMDとかいろいろ出てきましたが、今はwebpackが非常に勢力を拡大しています。このwebpackが後のGulpとかでやるような内容まで引き取っているというようなところが現在の状況です。
これをnpm trendsで見ると圧倒的にwebpackが一強の時代になっていると。
昔を遡ってみるとaltJSと言われる、JavaScriptをそのまま書くのではなくてJavaScriptをいったん別の言語で書いてそれをJavaScriptにコンパイルしようという文化があります。古くは2000年代からHaxeがありましたが、その後はCoffeeScriptとTypeScriptと来ていて、この辺は結局TypeScriptが一強の時代になっているというような状況だったりします。
こっちはGoogleトレンドで見たものですが、これもグラフで見るとTypeScriptがずっと伸びているという状況がわかります。
表現系ライブラリはThree.jsが強い
表現系ライブラリはどうかということで、これは昔のFlashのようなインタラクティブコンテンツを作るためのJavaScriptのフレームワークです。これはいくつか2010年代初頭にたくさん出てきていましたが、WebGLとかCanvasを使う系のライブラリですね。これはもう今はThree.jsとかPixiJSに集約されてきたというような状況が見えてきます。
これもGoogleトレンドで見るとこんな感じで、Three.jsがこの界隈では一番強いですが、CreateJSとかPixiJSは、この赤と青のところでラインが入っている。
ここの傾向から見ると、このインタラクションはCanvasとかWebGLを使う系のものは少しずつ下がってきていて、これはライブラリが新しいのが出ているわけではないので、ここから読み取れることとしましてはインタラクションデザインの分野自体が市場が縮小していることを1つ読み取れるのではと思っています。
では次の話にいきましょう。
こういったところを見ると、群雄割拠の時代は終わりを告げ、高度化を目指す時代になってきたように捉えています。これを具体的に示すのにReactの話をしていきましょう。
Reactというのは書き方がどんどん変わってきています。最近だとHooks APIを使ったコードの書き方をしています。昔だとクラスコンポーネントで書いたりとか、もっと昔だと.createClassというメソッドを使ってクラスのような挙動をするとかのコンポーネントの作り方をしていました。
Reactもどんどん書き方が変わってきています。書き方つまりコードの見える部分だけではなくて、内部のアーキテクチャもStack方式というものからFiber方式というものに変わってきています。これは何が変わってきているのかというと、Fiber方式はユーザーインターフェースの操作を阻害しないようなかたちで、Reactの更新処理を分割するみたいなところのアーキテクチャです。
そのパフォーマンスの向上であったりとか、アプリケーションを触ったときに快適に使えるようにみたいな思想があってのアーキテクチャです。これはReactで、そういうより高度な技術に発達してきている。
これは他のライブラリ、例えばVue 3。Vue 3は今年リリースされるものだと思っていますが、まだα版、β版の段階です。このVue 3もComposition APIと呼ばれるReactの関数コンポーネントに近いような書き方を搭載している一方で、パフォーマンスの向上としてより高速に動くとか、より小さなJavaScriptライブラリとして動くとか、そういったいくつかの機能向上が公式サイトからアナウンスされています。
隣のAngular。Angularも2020年の2月、今年の2月にAngular 9が出ましたが、Googleが作っているフルスタックフレームワークですね。これはAngular Ivyと呼ばれるレンダリングエンジンの刷新が行われていて、それがデフォルトになっています。そのIvyというレンダリングエンジンは何なのかというと、より小さなライブラリとして動くし、より早く動くみたいなところのエンジンになります。
ここから読み取れることとしてはReactもVueもAngularも、新しい何かを置き換えるというわけではなくてそのライブラリの中で進化しようとしていることです。そのことが、ここの紹介から読み解けると思います。
では次の話に移っていきます。ちなみに今回ハッシュタグで#icspatchというハッシュタグを付けていますので、ぜひここで聞いて気になった点とかはツイートいただけるとみなさんうれしいです。
JAMstackアーキテクチャは静的HTML文を作る
次はICSが取り組んでいることを紹介していきます。そういった時代背景の解釈をしている中で、ICSはどう取り組んでいるのかという話をしていきます。ICSが取り組んでいることを今日は3つお話しします。JAMstackアーキテクチャ、UI体験の改善、制作ルールの改善という3つのセクションに分けて説明していきます。
まずはJAMstackアーキテクチャと呼ばれるものを説明します。JAMstackとはWebアプリケーションの新しいアーキテクチャで、フロントエンドの技術で静的HTML文を作って、それを静的にファイルを配信するというものです。シングルページアプリケーションのような挙動をして動かすというものになります。
普通のWebサイトをHTMLとCSSで作って普通に静的サイトをアップするのと何が違うのかというと、シングルページアプリケーションをJavaScriptのエンジンなどよりも高速に動かすアーキテクチャが入っているところが特徴です。他にもGitで自動にビルドするとか、そういう話も入ってきます。こういった特徴のあるJAMstackをICSでは導入しています。
自社のオウンドメディアをJAMstackで構成
去年からICSではICS MEDIAというオウンドメディアのサイトを運用していますが、このサイト自体がJAMstackの構成でできています。ページ遷移とかもめちゃくちゃ速くなるようにがんばって作っていますね。こういう検索ボックスもwebpackとかを入れると打った瞬間に検索ができるようになっていて、かなり高速なアーキテクチャで作っています。
なぜこれが実現できているのかというとJAMstackの構成で作っているからです。JAMstackで作るとなぜ速くなるのかですが、ちょっと振り返ってみますと、もともとこのブログ形式のかたちを取っているサイトは、もともとはWordPressで運用していました。
これをNuxtとAMPの構成に変更しました。リニューアルしてからだいたい1年経ったので、どういう効果があったのかみたいなところをこのセッションの中で説明していきたいと思っています。
Lighthouseのスコアが80点から100点に改善
まずはLighthouseのスコアに関して、WordPressのときはよくて80点ぐらいのスコアだったのが、去年(2019年)の7月時点で、このスコアを100点取れるように改善しました。
シングルページアプリケーションとして起動するので、Nuxtの中身はVue.jsですが、シングルページアプリケーションはとてもサイトの高速化に有利です。SPAでルータ遷移といって、シングルページアプリケーションだとそのブラウザでアドレスを変えてページごと切り替えるのではなくて、画面の中のここの部分だけ変わるというのをすり替えられるんですね。
なので普通にWebサイトを閲覧するよりもかなり高速になるというところがあります。
シングルページアプリケーションはJavaScriptで動くので、JavaScriptで作るとSEO的にタグが出ないから不利じゃないかという話がよくありますよね。でも、このNuxtのいいところはソースコードの中身、本文の内容であったりとか、FacebookやTwitterのとかOGPとかそういった情報も静的に書き出すこともできるので、SEO上の弱点はほぼないです。
自動的にリンクを先読みする機能、インスタントクリック
他にも先ほどお見せしたサイトの中でサイト遷移を高速化する仕組みみたいなものがあって、インスタントクリックというものが入っています。これは何かというと、ページをスクロールしてきたときにリンクがページの中に入ったときに自動的にリンクを先読みするという機能が入っているんです。
これはNuxt側にその機能が入っているので、それを利用しているというのもありますが、Nuxtで管理していないところ、AMPと併用しているところもリンクにマウスオーバーしたらマウスオーバーした瞬間に次のページの情報を読み込むみたいなことをしているので、体感として高速に見えるみたいなところも実装していたりします。
そういった表示速度の高速化する観点でやったところ、これはGoogleアナリティクスの結果の実測値で、改善前と改善後で見たときに左下のところで-75パーセントと書いてありますが、読み込み時間が75パーセント短縮された、だいたい4倍ぐらい速くなったという結果がGoogleアナリティクスから出ているので、確実にサイトのレスポンスはよくなったと思っています。
JAMstackの構成にしたことで、原稿管理はマークダウンで管理するように変更
次はWordPressからJAMstackの構成にしたことでCMS観点でどういうことがあったかを紹介します。原稿管理はすべてマークダウンで管理するようにしました。
WordPressの中はけっこう自由に書けたりするので、今でいうとWordPressのGutenbergで書けますが、原稿ファイルは一元管理がしにくかったり、中身のフォーマットにいろいろ独自性が出てしまったりします。だから、マークダウンで完全に固定化することによって「データポータビリティ」と書きましたが、例えばこのNuxtの構成から別の技術にしたときにもただのマークダウンだから移植しやすいというメリットがあるという構成にできました。
今度はWordPressからJAMstackにしたことで悪くなったことを説明します。ビルド時間がめちゃくちゃ掛かるようになりました。これはNuxtとかを使っている人だとわかると思うんですが、ちょっとしたページを更新しようとしてもだいたい1分から2分ぐらい掛かってしまうというのがあります。
Nuxtだとビルド、スタート、ジェネレートというコマンドを実行して、ICS MEDIAの場合はAWSを使っているので、AWS S3にポンと放り込むのにそれも時間が掛かるので、WordPressで更新ボタンを押してすぐに反映できたことが、JAMstackではできなくなったなというに不便を感じています。
あとは予約公開ができない。これは作ればできるでしょうが、なかなかできないところというので、これが反省点としてあります。
(次回につづく)