grdの作者が考える、いまフロントエンドエンジニアに求められる「速度という機能」

「サイトの表示に3秒以上かかると、訪問者の53%がそのサイトから離脱する」
Googleが公開した上記のドキュメントは、Webの「使いやすさ」とは、スピードと不可分なものであることを示しています。

「パフォーマンスはサービスが持つべき“機能”の一部」と語るのは、『超速! Webページ速度改善ガイド』の著者の一人である泉水翔吾（せんすい・しょうご／ @1000ch ）さん。彼は、前職の株式会社サイバーエージェントから現職の株式会社メルペイに至るまで、フロントエンド領域を中心にキャリアを築いてきた、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の新しい標準技術が、アイデアの種になる