grdの作者が考える、いまフロントエンドエンジニアに求められる「速度という機能」
Webパフォーマンスの改善に、並々ならぬ情熱を傾けるエンジニアの泉水翔吾（@1000ch）さん。氏の手がけるOSSはこの情熱を体現するかのように、パフォーマンス改善にフォーカスしたものが多数あります。なぜWebパフォーマンスにこだわるのか、そして現在のフロントエンドエンジニアに求められる技術を聞きました。
1
「サイトの表示に3秒以上かかると、訪問者の53%がそのサイトから離脱する」
Googleが公開した上記のドキュメントは、Webの「使いやすさ」とは、スピードと不可分なものであることを示しています。
「パフォーマンスはサービスが持つべき“機能”の一部」と語るのは、『超速! Webページ速度改善ガイド』の著者の一人である泉水翔吾（せんすい・しょうご／ 
OSS活動においても、Flexboxを用いたCSSグリッドフレームワークのgrdや、画像の遅延読み込み用ライブラリのlazyload-imageなど、数々のライブラリを生み出してきました。
そんな彼に、現代のフロントエンドエンジニアに求められる要素とは何か、そしてOSS活動が彼のキャリアにどんなプラスの変化をもたらしたのかを聞いてみました。その回答には、「ユーザーやエンジニアにとっての使い勝手」にこだわり続けた泉水さんの哲学が現れています。
- 「ネットワーク」「レンダリング」「スクリプト」が、フロントエンドを構成する3要素
- 「解くべき課題にフォーカスすること」がライブラリ設計の肝
- Webの新しい標準技術が、アイデアの種になる
- 世界中のエンジニアが、Webを支えている
「ネットワーク」「レンダリング」「スクリプト」が、フロントエンドを構成する3要素
──フロントエンドエンジニアにとって、「どうやって高速なサイトを作るか」は重要なテーマです。それを実現するには、どんな知識を習得する必要があるのでしょうか？
泉水 前提として、「Webブラウザがどのように動いているのか」を知ることが重要です。この知識がなければ、何をすれば動作が速くなるのかを理解できません。近年、プラットフォームとしてのWebの重要性が増していることに比例して、この前提知識もさらに重要になってきました。
また、HTMLやCSS、JavaScriptといったフロントエンドの知識だけではなく、バックエンドやネットワークの知識もなければパフォーマンス改善が難しくなっています。例えば、ReactやVue.jsなどでサーバーサイドレンダリングをする場合、バックエンドのNode.jsがどのように処理しているかなどを理解できなければ最適化できないからです。フロントエンドエンジニアが身につけるべき知識は、以前よりも広範にわたるようになってきました。
泉水翔吾さん：大学卒業後、SIerに入社し、バックエンド、WindowsアプリケーションのGUI開発などを担当する。2012年、株式会社サイバーエージェントに転職しWebの世界へ。Webの技術に没頭するかたわら、Webパフォーマンス、アクセシビリティなどに関心を持つように。その後、現職である株式会社メルペイに入社し、現在は同社でエンジニアリングマネージャーを務める。Webパフォーマンスに関する執筆 / 発表活動も盛んに行っている。
──泉水さんが執筆された『超速! Webページ速度改善ガイド』では、「ネットワーク、レンダリング、スクリプト処理の三要素が、フロントエンドにおける重要な処理」である旨が書かれていました。それぞれ、どういう処理でしょうか？
泉水 ネットワークはWebページを構成するデータを取得する処理で、Webのパフォーマンスに大きな影響を与える要素です。
例えばiOSやAndroidのネイティブアプリの場合、基本的に全てのアセットが利用開始時点で端末にダウンロードされています。初回のダウンロードさえうまくいけば、後続の処理では最低限の動作が保証されるわけです。
ですがWebページの場合、画面遷移時にHTML情報の取得に失敗すれば機能そのものが使えなくなります。実装にあたってもこの前提を意識する必要があります。
──サービス可用性を高める上でも、ネットワークの重要性は高いわけですね。
泉水 ネットワーク通信の流量や頻度を減らすため、昔からたくさんの工夫がされてきました。例えば、リクエスト回数を減らしたり、アセットをなるべく小さくしたり、などの手法です。さらに、CDNを用いることでクライアントとの物理的な距離を縮めるなどの手法にまで発展しました。
このように、時代とともにネットワーク処理を改善する手法は進化 / 発展していますが、そもそもHTMLがなければ後続のリクエストができないので、一発目のリクエストが非常に重要だという原則はずっと変わらないですね。
──次はレンダリングについて教えてください。
泉水 レンダリングは、取得したアセットを組み合わせてページを構成するピクセルデータを画面に表示するまでの一連の処理です。あるいは、画面をスクロールしているときや、何かをアニメーションさせる際、画面を更新していく処理もレンダリングの一部です。
対話型の処理を行うページやアニメーションが重要なページにおいては、レンダリング処理の高速化も必要になります。ユーザーは、必ずしも性能のいい最新端末を使っているとは限りません。そういった方々の環境でもスムーズに動くようにレンダリングを最適化することは、フロントエンドエンジニアの役目だと思っています。
続いて3つ目の要素であるスクリプトですが、主にJavaScriptによる動的な処理です。かつて、ほとんどのWebサイトは文書的であり静的なものがほとんどでしたが、近年では動きの多いアプリケーションのようなWebサイトが増えています。PWA（Progressive Web App）というキーワードがよく語られていますが、これはWebをよりアプリの体験に近づけるという概念です。その概念を実現する上でも、JavaScriptは非常に重要になります。
──Webにアプリ的な体験が求められると考えると、パフォーマンス改善は今後さらに重要になってきそうですね。
泉水 はい。パフォーマンスは“機能”だと思っています。だからこそ僕は、仕様が決定した後の段階で「どうパフォーマンスを向上させるか」を考えるだけではなく、仕様策定のフェーズにもエンジニアが入り、パフォーマンスに関して主体性を持つ必要があるとも思っています。なぜなら、デザインや仕様そのものがパフォーマンスの出づらい作りになっていれば、エンジニアだけではそれ以上の高速化ができなくなってしまうからです。
「解くべき課題にフォーカスすること」がライブラリ設計の肝
──その前提を踏まえて、泉水さんが過去に作成されたOSSの話をさせてください。リポジトリを拝見すると、タスクランナーにおいて画像の最適化を行うgrunt-image、gulp-imageや画像の遅延読み込みを行うlazyload-imageなど、フロントエンドのパフォーマンス最適化に結びつくものも多いですよね。
泉水 特別にそこを意識しているというよりも、基本的に僕が作っているOSSは「自分で使いたいもの」を作っているので、結果的にそうなったのかなと思います。
例えばgrunt-imageやgulp-imageは、業務で画像の最適化処理が必要になったので、自動化するためにプラグインを作りました。それから、僕はJPEGやPNGをWebPに変換するWebPonizeというMacのアプリケーションも開発していますが、これも「アプリを用意しておけば、一緒に働いているデザイナーさんたちが便利に使ってくれるかな」と思って作りました。
──作成されたOSSの中でも、Flexboxを用いたCSSグリッドフレームワークのgrdは多くのスターを集めています。ライブラリのアイデアは、何をきっかけに発想したのでしょうか？
泉水 もともと、友だちが「こういう感じのライブラリがあったらいいね」とgrdのコンセプトに近い話をしていて、それをベースに開発しました。当時はCSS gridなどの仕様がありつつもブラウザが十分にサポートしていない時代でしたから、Flexboxを用いて、かつIE11でも使える汎用的なライブラリというイメージで設計をしていきました。
──使いやすいライブラリにするために、どんなことを大切にしましたか？
泉水 可能な限り、余分な要素を省くことですね。僕は基本的にOSSは小さいものを組み合わせて使う方が柔軟性が上がると思っていて、ライブラリを作る際にも解決すべき課題をなるべくひとつにしたいと考えています。
grdの場合も、パフォーマンスの邪魔にならないように、余計な機能を入れず小さなライブラリに留めることを心がけました。grdはライブラリのファイルサイズが非常に小さいのですが（gzipp圧縮した場合は321bytes）、意識してファイルサイズを小さくしたというより、なるべくミニマムな機能にしようと考えていたら結果的にそうなりました。
──過去のライブラリも、「解くべき課題にフォーカスする」という方針で開発されているものは多いですか？
泉水 そう言われてみると、ライブラリには自分が本当に欲しい機能だけしか実装していないですね。たとえ苦労して実装したものでも、それが必要ない機能であれば省きます。
先ほども話題に上がったgrunt-imageやgulp-imageなどが良い例だと思います。これは画像の最適化をひとつのプラグインの中で完結させるというコンセプトで開発していますが、あくまで“最適化”にフォーカスしているので、画像のリサイズ機能などを入れていません。
──オールインワンで広域な機能を網羅するライブラリもありますが、泉水さんが作るライブラリは違う方向性を目指しているのですね。
泉水 BootstrapやSassなどは多機能なライブラリの代表だと思うんですね。これらはもちろん非常に優れたライブラリですが、良くも悪くも、不要な要素が多いです。例えばBootstrapを使う際、ボタンがひとつ欲しいだけだとしても、CSSやJavaScriptなどを読み込まなければうまく動かないケースがあります。
いわば、こういったライブラリは十徳ナイフのような面があるわけです。「ある機能が使いたいだけなのに、他のものも一緒についてくる」という。便利だけれど、便利であるがゆえに使いにくさを生んでしまう部分もあると感じています。
Webの新しい標準技術が、アイデアの種になる
──自分が作ったもの以外に、他の方が作ったOSSのコードを読んでインスピレーションを受けることもありますか？
泉水 設計やコードが美しい方を挙げると、TJ Holowaychuk（@tj）がやはりすごいなと感じます。彼はNode.jsフレームワークのExpressや、テンプレートエンジンのJadeなどを作成したエンジニアです。
──過去にこの連載に登場してくださった川口和也さんも、TJ Holowaychukの作るライブラリを絶賛していました。
泉水 tjは神ですね。彼の作るライブラリは、1つひとつのモジュールが全く余計なことをしません。Expressのソースコードを読んでみても、各モジュールの分離のさせ方などが絶妙だと感じます。
もうひとつ、最近ではGoogleのChrome teamが開発したquicklinkというライブラリが素晴らしい実装です。これは、Webページの文中にリンクが存在している場合、モバイルディスプレイの画面内（ビューポート）にそのリンクが入ってくると、Webページを先読みするというライブラリです。この実装が非常によくできています。
かつて、「特定の要素がビューポートに入ったかどうか」は、スクロールイベントを見なければ判定できませんでした。しかし最近では、Intersection ObserverというAPIを使うことで、スクロールイベントを監視せずにAPIのコールバックでビューポート情報を取れるようになりました。quicklinkはそのIntersection Observerの機能をうまく活用して実装されています。
さらに、ユーザーのネットワーク環境にも配慮した作りになっています。例えば、ネットワークが弱い環境でリンク先読み機能が常時オンになっていると、かえって使い勝手が悪くなってしまいますよね。そのため、Wi-Fiに接続されているときだけ処理を実行するという工夫をしているんです。
新しいWeb標準技術を綺麗に組み合わせることで、これらの機能を実現しています。なおかつ、ライブラリのファイルサイズは圧縮後はわずか782bytesに収まっていて。本当によくできていると感じました。
──泉水さん自身も、Webの新しい標準技術の情報を元にして新しいライブラリを発想することはありますか？
泉水 僕は自分のことをWebオタクだと思っていて、「どんなWeb標準技術が登場してきたか」「どういう技術が今後は出てきそうか」のアンテナを常に張っています。
「この技術とこの技術を組み合わせれば、こういうWebパフォーマンスの最適化ができるから、そうした操作を簡単にしてくれるものを作ろう」と発想することもあります。自分の関心のある要素技術を組み合わせることで、新しいアイデアが生まれているという側面はあるでしょうね。
世界中のエンジニアが、Webを支えている
──OSS開発に携わることは、非常に利点が大きいように思えます。「これからOSSに携わりたい」という方は、何からスタートするといいでしょうか？
泉水 シンプルに「自分が作っていて楽しいもの」に取り組んだ方が、モチベーションは維持できます。僕自身もこれまで、自分が実現したいことや、欲しかったツールを作ってきただけです。
それから、公開することを恥ずかしがらない方がいいです。自分が「これ、ひどいな」と感じるようなコードでも、公にしていいと思います。単なる写経でも、車輪の再発明でも、コピーでもいい。まずは公開して、小さくてもいいから成功体験を得ることが大事だと思います。
そのコードを誰かに見られて卑下されることは、まずありません。世の中のエンジニアはみんな自分の味方だと思って、発信した方がいい。さまざまな意見やPull Requestをもらえるチャンスが広がったと考える方がいいです。
──公開して誰かに使ってもらうことで、ライブラリへ良いフィードバックが集まり、利便性も高まりそうですね。
泉水 フィードバックが改善のきっかけになった経験は僕もあります。reachable-urlsというライブラリを作ったのですが、これは、テキストデータをライブラリに食わせると、その中に含まれているURLに到達可能（HTTP statusが2XX）なのか到達不可能（HTTP statusが4XX）なのかをチェックしてくれるものです。
僕は雑誌などに寄稿させていただく機会がよくあるんですが、編集担当の方が「こういうツールがあったらいい」とおっしゃっていたアイデアを元にしたものです。その後、編集部の他の方々が使ってくださるようになって、要望もたくさん来るようになりました。
最初は、文章に含まれているURLのリストを、OKのものもNGのものも全て出していました。でも編集者の方から「NGのものだけ出してもらえる方が使いやすい」という意見が挙がったので対応を入れたり、「処理の進行状況を知りたい」という要望に応えてローディングのアニメーションやインジケーターを出したりしました。自分では気づけなかったような改善点が、他の人の目を通すことでいただけたわけです。
──ライブラリを公開することの意義がよく現れていますね。最後に伺いたいのですが、泉水さんはキャリアの全般にわたって“Web”に携わり続けてきましたが、この領域の面白さとは何にあると考えていますか？
泉水 いくつかありますが、まず「URLだけでサービスをシェアできること」です。サービスを誰かに使ってもらいたいとき、アプリをダウンロードしてもらう必要がなくテキストひとつで共有できるのは、絶対的なメリットだと思っています。
それから、「特定の企業が支えているわけではないのに、人々の善意によって発展が続いていること」も本当にすごいです。例えば、Androidプラットフォームの仕様はGoogleの人々が決めていますし、iOSプラットフォームの仕様はAppleの人々が決めていますよね。でも、Webはそうではありません。
特定の企業や個人に依存せず、世界中のWebに関わる人たちが「こういう機能があるべきじゃないか」と議論しながら仕様を決めています。この仕組みが成り立っているWebは素晴らしいものだと、僕は思っています。
取材・執筆：中薗昴
