こんにちは、編集長の白石です。

この記事は、9月24日に開催されたHTML5 Conference 2017に登壇したエキスパートに、お話されたセッションのトピックを中心に語っていただこうとういものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回お話を伺ったのは、html5j パフォーマンス部を運営していらっしゃる竹洞 陽一郎さんです。

▲HTML5 Conference 2017セッション風景 （写真提供：html5j　撮影：刑部友康）

竹洞さんのセッション「テクニックではなく、今、本気で取り組むべきWebパフォーマンス」に関するスライド資料は、こちらで公開されています。

民法（債権法）が改正されて、何が変わる？

白石: 民法（債権法）が改正された、ということに注目なさってるそうですね。

竹洞: はい、民法の大規模な改正法案が今年5月に成立しました。3年以内に施行されることになっており、備えが必要です。様々な改正項目がありますが、中でも品質の担保を行う義務が明文化されたことで、ソフトウェア業界にも大きな影響が及ぶものと考えています。

白石: 具体的にはどういうことなのでしょうか？

竹洞: 「瑕疵担保」っていう概念がなくなるんです（参考: 改正民法が成立、「瑕疵担保責任」などシステム開発契約に影響大 (ITpro)。

今までは「瑕疵担保」という概念があったおかげで、とりあえずは品質を担保しない状態で納品を行い、その後の瑕疵期間で問題を修正していく…というのが一般的に行われていました。ですが今後は、納品時に一定の品質を保証することが開発側に求められるようになります。

白石: そのことが、どういう影響をおよぼすと考えられますか？

竹洞: 私としては、ソフトウェア品質が全般的に向上することで、市場が健全化すると考えています。

品質への理解が低い市場は、必ずと言っていいほど衰退するんです。 消費者が品質の善し悪しが判断できない状態だと、価格が一番の判断材料になります。 そうなると結局、品質を犠牲にした価格競争にならざるを得ない。

白石: 「安かろう悪かろう」が当たり前になってしまうわけですね。

竹洞: そう。そういうスパイラルに陥らないためには、品質への意識を高く保つ必要があるんです。

例として適切かはわかりませんが、たとえば麻薬の売人って、品質にものすごく気を使うんです。 質の悪い麻薬が出回るようになると、価格に対する期待と同程度の「ハイ」の状態を得られず、その結果、価格の下落を招き、結局市場が衰退してしまうからです。こうした現象を、アメリカの中古車市場の分析から「情報の非対称性」として研究したジョージ・アカロフ博士は、2001年にノーベル経済学賞を受賞しています。

「品質保証」がウェブ業界を変える

白石: しかし、品質保証が義務付けられるとなると、開発のコストが上がるということになりませんか？

竹洞: それはあり得ます。そのことが、受託開発のビジネスなどをより難しくしてしまうことも考えられます。

例えばウェブ制作会社は、一般的には納品後に入金が入るという仕組みになっていますよね。 だから、まずは品質がそこそこの状態で納品してしまう…ということも起きるわけです。 パフォーマンスはその悪い例で、まずはチューニングしていない状態で納品する。すると、後でパフォーマンス・チューニングの依頼が来てまた売上につながる…なんて事情も実際にはあるわけです。

こうしたこれまでの商慣行が崩れてしまう可能性はありますね。 品質保証が義務付けられるせいで、納品までにより時間がかかるようになるとすると、入金が遅くなるということに繋がる。しかし、民法債権法改正では、部分単位やステージ毎の請負金額の要求ができるようになっています。

白石: それだけ聞くと、受託開発や制作を行っている企業にとっては、ただただ厳しくなるようにも聞こえますね。 そもそも、「品質を保証して納品」ってどういうことなんでしょう？ 完璧なソフトウェアを作らねばならない…なんてそもそも無理だとも思うのですが。

竹洞: その点については安心していいと思います。 「品質を保証する」というのは、「完璧な製品」を意味しているわけじゃないんです。 テスト項目について顧客と合意し、その結果を提出すればいい。実は、ソフトウェア品質には、V&Vといって、Verification(検証)とValidation(妥当性確認)という二つの概念があります。

検証(Verification)とは、仕様・設計・計画などの要求事項を満たしているかどうかの確認です。妥当性確認(Validation)とは、機能や性能が本来意図された用途や目的に適っているか、実用上の有効性があるかの確認です。Webパフォーマンスは、品質においては、妥当性確認にあたります。

従来、ソフトウェア開発における「品質」、特に受託開発においては、検証確認が主体でした。もちろん、応答速度の遅延などで使いものにならないという妥当性確認もあったものの、それはハードウェア性能であったり、データベース設計の問題であったりと、「表示」そのもののロジックに原因はあまりなかったのです。

要求仕様の実現という意味での検証については、仰るとおり「完璧な製品」というのは、ほぼ存在し得ない。それは、ソフトウェアが、論理記述であって、物理法則の縛りがなく、かつ、連続性の保証がないためです。

連続性の保証とは、物理法則であれば、100Kgの重さまで耐えられるテーブルであれば、当然ながら、80Kgや10Kgなど、100Kg以下の重量に耐えられることです。しかし、ソフトウェアは二値論理がベースであるために、100という値で大丈夫であっても、80や10という値で大丈夫であるという保証がない世界です。

2002年に亡くなられた、オランダの著名な計算機科学者で、構造化プログラミングの提唱者でチューリング賞を受賞しているエドガー・ダイクストラ博士が「テストは誤謬を見つけることはできるが、それがないことを証明することはできない」と指摘しています。

ですから、バグや欠陥がないことを保証するというのは無理なんです。

白石: なるほど、それなら少し安心です。バグや欠陥のないソフトウェアなんて不可能ですし。

竹洞: 品質についても顧客との合意内容に盛り込む必要が生じる、ってことですよね。 そうした合意があるのとないのとでは、品質に対する意識が全然違ってきます。品質については、検証として従来もやってきたことです。ところが、WebがソフトウェアのUIの主体となることによって、今まで問題にならなかった「表示」に関するロジックが突如、問題となり始めた。突如といっても、もう20年ぐらいになるわけですが…

その部分は、検証ではなくて、妥当性確認なんですが、妥当性確認のテストのノウハウが日本では普及していなかった。今、そこが問われているわけです。

白石: なるほど。「完璧な製品を作る」ことが品質保証なのではなく、「妥当性品質に対してどこまで保証するかを明確にする」ということなんですね。

竹洞: そうです。そうして、妥当性品質についての期待値を高く保つことは、Webに関する業界として必要なことだと思いますよ。

例えば日本の住宅市場は、品質保証がうまくいっていない例だと思うんです。 日本の住宅って、非常に寿命が短いじゃないですか。その理由は様々ですが、一つに中古住宅に対する品質の期待値が低いことがあると思っています。 品質保証がない空き家を買うくらいなら、新築のほうがいいって心理です。

白石: 確かにそういう一面はある気がしますね。ぼくは安さに釣られて中古住宅を買ったクチですが(笑)、一生住めるなんて少しも期待してませんし。

竹洞: それって、結局その家はいつか捨てることになるってことで、財の蓄積が進んでいないとも言えると思うんです。 社会的に見ると、将来世代に引き継ぐ財が形成されていないとも言える。財の蓄積が期待できないと、そこの投資は進まない。お金が集まってこないのです。

ウェブのように技術がどんどん進歩していく世界に財の蓄積は有り得るのか？システム構築費用は5年で償却されるのであれば、5年持てばいいじゃないか？という考えられるのは、仰るとおりです。

しかし、プレゼンテーションとしてのUIデザインと、データとしてのコンテンツやユーザのデータは分けて考えるべきで、だからこそ、HTMLとCSS、JavaScriptで役割分担をしているわけじゃないですか。システムの永続性というものを考慮してWebサイトの設計を行うことは非常に重要なのです。

減価償却期間の5年も持たない、3年程度で捨てざるを得ないとなれば、企業財務的にはそこはできるだけ安く済ませるべきなのです。しかし、品質が保証されて、減価償却の5年を超えて使えるとなると、将来価値が上がる。企業財務的にはおいしいお話なのです。そこに気付いてほしい。メンテナンス費用は当然発生するでしょうけど、新規で作るより安いですし、何より「継承」できることが大きなメリットなんです。

UIデザインや技術力だけで勝負しているWeb制作会社さんは、その点に、早く気づかれた方が良いと思います。お金を握っている経営者や財務担当者は、別のロジックで判断しているわけですから。

ですから、ウェブサイトも、いつか捨てるものとなれば、そこに予算を掛けようとは思わない。品質が保証されないのであれば、なおさらのことです。

「お客様からあまり予算をいただけない」と嘆くことがあるかと思いますが、その背景には、品質が保証されていないので修正するより作り直した方がいいと考えられていること、いつかWebサイトは捨てて新しく作るものと考えられている背景は認識しておくべきだと思います。

ウェブサイトの品質を決める3つの要素

白石: では具体的に、ウェブサイトにおける品質を保証するというのは、何をすればいいんでしょうか？

竹洞: ウェブサイトの品質は主に3つの要素から成っていると言っていいでしょう。

一つはアクセシビリティ。 一つはセキュリティ。 最後がパフォーマンスです。

Webサイトの三大品質

これらはそれぞれJISで規定されてもいる重要な指標です。これらをしっかり担保していく体制づくり、それがウェブサイトの品質保証に繋がります。

白石: ウェブサイト制作にも、これらを担保するワークフローを確立していくべきということですね。

竹洞: そうです。そしてこれらは、運用と一体になって改善していくべきものでもありますので、DevOpsの観点から考えるのも重要です。

ただ一つ不思議なのが、日本でDevOpsに関して述べている文献や書籍って、ほとんどの場合品質保証のことが抜けてしまっているんですよね。 品質に対する意識が高まらない原因は、こういうところにもあると思います。

DevOps

ウェブサイトの品質を高めるための心構え

白石: 品質を向上させるためのコストが低く見積もられがちというところもあるんでしょうか。

竹洞: というよりは、そのコストが認識されていないというのが正しい気がします。 「品質、費用、期間の3要素を同時に満たすことはできず、トレードオフの関係にある」といった、プロジェクトマネジメントやソフトウェア開発見積りの基本もあまり浸透していない感覚がある。

白石: なるほど。当たり前の話ですが、品質を高めようとすれば、時間的、金銭的なコストを支払う必要があるということですね。

竹洞: はい。そして品質保証が当たり前になれば、品質保証のためのコストがかかるのも当たり前になる。今は、その当たり前のコストを払っていないだけとも言えるのです。

白石: では、そうした品質保証、特にパフォーマンスについて、状況を改善していくにはどんな知識が必要になるんでしょう？

竹洞: そうですね、小手先のテクニックはたくさんありますし、いろんなところで語られてもいますので、もう少し根源的なところから考えると、結局「基礎」と「長期的な視野」が重要になると思うんです。

基礎というのは、コンピューターやネットワークに関する基本的な知識。 長期的な視野と言うのは、数年後にインターネットがどうなっているか、といった話です。

白石: なるほど。

竹洞: 例えば、パフォーマンスに関する話を突き詰めていくと、意外なほどハードウェアに関する知識って大事なんです。 パフォーマンスって、最終的には絶対にハードウェアに依存するわけですからね。

例えば、とある大規模サイトで遅延が発生していたんですが、その原因を追求するのすごく大変だったんです。 アプリケーションをいくら調べても、データベースのクエリをいくら見直しても、ネットワークの状態を見ても、原因がわからなかった。

白石: 結局、どんな原因だったんですか？

竹洞: そのサーバはVMWareで仮想化されていて、サーバ負荷に応じてCPUリソースが動的に割り当てられるようになっていました。ただ、あらかじめ割り当てられているCPUリソースが足りなかったせいで、CPUの動的割り当てが頻繁に発生してしまっていたんです。 その割り当てが行われる際に、サーバの処理が遅延してしまっていたんですね。

白石: それは深い原因ですね…

竹洞: ここまで奥深くに原因がある場合って、ハードウェアを含めたアーキテクチャ全般の知識が必要になります。 だから結局、コンピューター全般の知識って必要だなと。だから私の会社では、入社したら最初の一歩として、まずPCを自作してもらうようにしています(笑)。

全てを変える、5Gネットワーク

白石: 数年後にインターネットがどうなっているか、というお話も聞かせていただけますか？

竹洞: はい、具体的には5Gネットワークの話になりますね。5Gはアプリケーションの作り方を含め、全てを変える可能性がある技術だと思っています。

白石: 5Gネットワークって全然知らないのですが、どんな感じなんでしょう？

竹洞: 大きく3つのトピックがあると考えています。

一つはネットワークスライス。インターネットを「輪切り」にするイメージで、用途に応じて別々のネットワークを提供していくようになります。

電波には周波数によって特性があり、サービスの特性に応じて周波数を割り当てて異なるネットワークを構成できるので、ネットワーク全体の利用効率が大きく向上すると考えられています。

ネットワークスライス

次に指向性アンテナです。今までは、基地局といういわば「傘」を中心として、そこから広がるように無線ネットワークが構築されていました。

しかしこれからは、パネル型のアンテナがビルの壁面に貼られるようになり、そこから端末と直接「ビーム」をやり取りするように通信を行います。通信の受信強度が高まるだけでなく、他の電波との干渉も減らせます。

指向性アンテナ

最後にモバイル・エッジ・コンピューティングです。これは、4Gですと、地域の基地局をまとめているRNC(Radio Network Controller)配下に、仮想サーバー（エッジサーバー）を設置できるようになるのです。 今まで携帯の会社はコアネットワークを公開していなかったので、これは大きな変化です。

モバイルエッジコンピューティング

これは分散コンピューティングの新たな可能性を示しているといえます。インターネットより手前でトラフィックを捌けるわけですから、サーバーの応答性も大きく向上します。

白石: へえ、知りませんでした！世界中のエッジサーバー上に、静的リソースのキャッシュを置けたりしたら、すごく速くなりそうですね。

竹洞: それだけではありません。エッジサーバーで可能な限り処理を行い、必要な処理だけインターネット上のサーバーに送るようにすることもできます。アプリケーションの処理を、エッジサーバーとインターネット上のサーバーで分担するというわけです。

もしくは、全てエッジサーバー上で処理を行うような、非インターネットのローカルなサービスを行うことも可能です。

白石: そうなると、アプリケーションの作り方も大きく変わってきそうですね。夢が拡がりますね…。5Gネットワークって、具体的にはいつ頃普及が見込まれているのでしょうか？

竹洞: 2020年の東京オリンピックまでには使えるようになるだろうと言われています。

10月12日に、NTTドコモ、富士通、富士通研究所がモバイル・エッジ・コンピューティングを使った高画質動画配信や映像解析を活用した人物検知システムの実証実験を行って成功した旨のプレスリリースを発表してています。

また10月13日には三菱商事が、この分野のリーディングカンパニーであるJIG-SAWと、モバイル・エッジ・コンピューティングの実証実験成功のプレスリリースを発表しています。

白石: ワクワクしますね。本日は民法から5Gネットワークまで、幅広いお話を聞かせていただき、ありがとうございました！

こんにちは、編集長の白石です。

この記事は、9月24日に開催されるHTML5 Conference 2017に登壇するエキスパートに、予定しているセッションのトピックを中心に、いろいろ伺ったものです。セッションの内容をより深く理解する手助けになるだけでなく、本記事単体でも面白く読んでいただけることを目指しています。

今回お話を伺ったのは、株式会社サイバーエージェントにお勤めの佐藤歩さんです（ネット上では「あほむ」「ahomu」のIDで有名）。 （プロフィールはこちら）

あほむさんのセッションは「最近のWebパフォーマンス改善について知っておきたいコト」（ホール 13:20-14:00）です。 （現在HTML5 Conference 2017は定員オーバーの状態ですが、無料イベントということもあってキャンセルも多めに出るらしいので、あきらめずにキャンセル待ちすることをお勧めします！）

パフォーマンスはなぜ重要か？を違う切り口から伝える

白石: Webパフォーマンスについて、「ベーシックな話を少々と、最近の動向」をお話されるということですね。

あほむ: はい、そうですね。まあ、まだセッションの内容はほとんど固まっていないので、当日は全然違った話をすることになるかもしれないのですが。

普通パフォーマンスに関する「ベーシックな話」というと、「なぜパフォーマンス改善は重要か」ということを語られることが多いと思うんです。でも、「パフォーマンスが重要」というのは、もうエンジニアには広く認識されているんですよね。

足りないのは、パフォーマンス改善を「開発者の自己満足」で終わらせないことなんじゃないかと。パフォーマンス改善が、自社のビジネスにどう寄与するのか。そこを考えないと、意味のないパフォーマンス改善を行ってしまう恐れもあるし、社内の理解も得られない。

「パフォーマンスは重要である」というメッセージを、そういう観点からも伝えたい気がします。それも他社の事例とか一般論から語るんじゃなくて、私自身が遭遇した実体験などを踏まえて語りたいな…と思ってます。

白石: それは面白そうですね！具体的には、どんな実体験になりますか？

あほむ: 例えば、弊社のサービスってSNSでWebページが拡散されることが、非常に大きな比重を占めているんです。つまり、TwitterやFacebookのアプリ上で、WebViewでページを表示されることがすごく多いんです。そうなると、実はブラウザのキャッシュにすら期待できないことが多い。弊社のサービスはiOSのユーザーが多いのでなおさらです（※）。

とはいえ、SNSを通じてたまたま遭遇した、っていう千載一遇のチャンスは活かさなくてはならない。そういう限定された環境でも最高のUXを実現するため、最大のパフォーマンスを発揮するにはどうしたらよいかを常に試行錯誤しているんです。

白石: なるほど。確かにそれは、パフォーマンスが非常に重要なシチュエーションと言えそうです。

あほむ: こういう例を含めていろいろ紹介できるといいかもしれません。URLさえあればどこからでもアクセス可能というのはWebの利点ですが、要はどんな環境で見られるかわからないということです。だから、Webのパフォーマンス改善には終わりがないし、少しでもその助けになるよう、常に新しいアイデアや技術が考案されています。そういう技術のうち、比較的新しくて、活用しがいのあるテクニックや仕様について、いろいろご紹介できればと思っています。

※弊社のサービスはiOSのユーザーが多いのでなおさら…Androidであれば、Chrome Custom Tabという仕組みでメインブラウザ（Chrome）とキャッシュなどのリソースが共有されることも期待できる。iOSは、Chrome Custom Tabに近いSafari View Controllerという仕組みがあるが、あまり利用されていない。

ページロードパフォーマンスの改善テクニック

白石: では、パフォーマンスを改善していくテクニックや仕様をいくつかご紹介いただけますか？

あほむ: Webパフォーマンスを考える際には、やはりページロード (ページの読み込み速度)と ランタイム （ページ実行中のパフォーマンス）に分けて考えるのが王道です。ページロードの改善については、最近だとHTTP/2の話が中心になると思います。

白石: なるほど、御社のサービスでは、HTTP/2対応はもうかなり進められている感じなのですか？

あほむ: はい。できるところからHTTP/2にしていくというアプローチで、現在は多くのサービスがHTTP/2を利用して動いています。

白石: 実際にHTTP/2に対応してみていかがですか？苦労した点とかはありましたか？

あほむ: 具体的な切り替え作業については、インフラの専門チームが実施してくれるので、あくまで開発側からの意見になりますが…ほとんど苦労していることはないですね。

白石: おお、本当ですか。それは素晴らしい。

あほむ: はい、HTTP/2に切り替えても、開発への影響はほとんどなかったという点はとても重要ですね。アプリケーションとネットワークで、レイヤーが違うから当然といえば当然なのですが、やはり実際に経験してみると、そのありがたさが実感できます。トレードオフがほとんどないにも関わらず、パフォーマンスの向上が見込めるのですから。

白石: でも、HTTP/2に切り替えたことで、本当にパフォーマンスアップするのか、懐疑的な意見も目にしたことがあります。実際のところどうなんでしょうか？

あほむ: うーん…実際のところ、それはありますね。HTTP/2にしただけだと、体感的に良くなったっていう実感があまりないのは、正直なところです(笑)。

白石: それも正直な意見として、貴重だと思います(笑)。

あほむ: 例えばHTTP/2でヘッダ圧縮されてデータ転送量が多少減ったとしても、アプリケーションで扱うデータが最適化されてなかったら、誤差みたいなレベルになってしまいますからね。HTTP/2によるパフォーマンス向上は、確実に効いているとは思います。ですが、実際のサービスでは、常に別のところにパフォーマンスのボトルネックが潜んでいて、効果のほどが見えにくいんですよね。

白石: 他には、ページロードの最適化で知っておいたほうがいいテクニックとかありますか？

あほむ: ほかには、コンテンツの圧縮にZopfliやBrotliを利用していますね。他にはResource Hintsなども使っているので、お話したいですね。

※参考記事：FRESH! Web パフォーマンス改善 〜サーバサイド編〜

白石: Zopfli…？そんな圧縮形式があるんですか？

あほむ: はい、ZopfliもBrotliも、どちらもGoogleが開発した圧縮形式です。

Zopfliは、圧縮の速度は遅いですが、そのかわりに圧縮効率は非常に良い。そしてgzipとの互換性があるので、gzipに対応したブラウザであればだいたい扱えるという大きな利点があります。

Brotliは、gzipとの互換性はありませんが、非常に効率のよい圧縮アルゴリズムです。こちらは現在のところ、Chrome, Firefox, Edgeでのみ利用可能です。

白石: Resource Hintsというのはどういうものですか？

あほむ: 利用するリソースを先読みするヒントをブラウザに与えるための仕様です。これを利用すると、現在のWebページに含まれていないリソースであっても、ブラウザに先読みさせることができます。dns-prefetch (名前解決を実行しておく）, preconnect （サーバ接続を行っておく）, prefetch （リソースのフェッチを実行しておく）, prerender （ページのレンダリングをバックグラウンドで実行しておく）といったタイプの先読みが可能です。 （筆者注: Jxckさんのブログで詳しく解説されています）。

ランタイムパフォーマンスの改善テクニック

白石: ランタイム （アプリケーション実行時）のパフォーマンスを向上させるために使用している技術にはどんなものがありますか？

あほむ: Intersection ObserverやPassive Event Listenersは利用しがいがあると思います。

Intersection Observerというのは、要素同士の領域が交差したり、もしくはビューポート（ユーザーに見えている範囲）に要素が入ったかどうかなどを検出できるAPIです（筆者注: Intersectionとは「交差」の意味）。これを利用すると、ビューポート外で行われる処理を抑制したり、遅延させたりすることが可能になるので、パフォーマンス向上には非常に効果的です。わかりやすいのは、img要素がビューポート内に現れるまで画像の読み込みを遅延させる…などですね。

Passive Event Listenersというのは、UIイベントが preventDefault() （デフォルトの動作をキャンセルする）されないことを保証するための仕組みです。

スクロールイベントなどは、 preventDefault() を行うことでブラウザのスクロール処理そのものをキャンセルすることができます。逆に言うと、ブラウザはスクロールがキャンセルされる可能性を考えると、イベントハンドラを実行してから実際のスクロールを行わなくてはならない。だから、イベントハンドラの実行に時間がかかったりすると、スクロール処理が詰まってしまうんです。これがスクロールジャンクと呼ばれる現象です。

ただ、実際に preventDefault() でスクロール処理を止めたいというケースは多くはありません。なので、「このイベントハンドラはpreventDefault()を呼ばないよ」ということをブラウザに伝える手段として用意されたのがPassive Event Listenersです。

（筆者注: これらも、Jxckさんのブログに詳しい解説がある。Intersection Observer Passive Event Listeners）

白石: 今おっしゃったIntersection ObserverやPassive Event Listenersは、全てのブラウザで動くわけではありませんよね？

あほむ: はい。なので、動作しないブラウザ用にFeature Detectionで分岐を設けたり、Polyfillも活用しています。

白石: なるほど。ただ、最初にお聞きした例だと「SNSで拡散されたページの最適化に注力している」というお話でした。こういうランタイム系のパフォーマンス改善って、SPA (Single Page Application) ではない通常のランディングページやメディアのサイトなどでも重要なのでしょうか？

あほむ: そう思います。先程も申し上げたように、SNSを通じてサイトにアクセスしてくれるのって、ユーザーと接触できる千載一遇のチャンスなわけです。そこからモバイルアプリへの誘導を行うこともできる。なので、そういう千載一遇のチャンスで少しでも機会損失を起こさないように、入念にパフォーマンスをチューニングするのは非常に重要です。

個人的には、jQueryを使った普通のWebサイトこそ、ランタイムのパフォーマンスにもっと気を使うべきだし、できるとも思います。jQueryのプラグインが最新の仕様に追従すれば、プラグインをアップデートするだけで恩恵を得られるわけですから。

ただ逆に、プラグイン側が対応してくれなかったりすると、プラグインの中に手を入れるわけにもいかず、対応が進まないということの裏返しでもありますけどね…悩ましい問題です。

パフォーマンス改善を「開発者の自己満足」で終わらせないために

白石: これまでご紹介いただいた様々なテクニックですが、これらを活用してパフォーマンスを実際に改善していくのは、実際には骨の折れる作業だと思います。そうした、パフォーマンス改善作業に投下するコストと、それによって得られるリターンについては、どのようにお考えでしょうか？

あほむ: はい、おっしゃるとおり、これらのテクニックをただ使って、目に見えない部分でパフォーマンスを改善しても、単なる開発者の自己満足に終わってしまいます。それを避けるためには、まずは正しく計測することと、それがビジネス上のKPIとどう関連付けているかを検証していくことが必要です。

まず計測についてですが、クライアントサイドのパフォーマンスを計測する指標は、現在も様々なものが考案され、利用可能です。

例えばFirst Paint。Webページの描画が開始されたタイミングを表す指標で、ChromeやEdgeでは非標準のAPIから値を得ることができます。

ただ、First Paintだけでは、コンテンツの表示が完了するまでの速度などについてはわかりません。最も重要なのは、ユーザーに見える範囲、つまりビューポートの描画がいつ完了するかです。

そういう観点での指標としてはSpeed Indexがあります。Speed Indexを計測する基本的な方法としては、描画中の画面をキャプチャして、最終的な表示結果が得られるまでにどれくらいかかるかを測るというものです。弊社のサービスでは、ページビューや直帰率といったKPIとSpeed Indexの間に相関関係が認められたため、Speed Indexを中心にパフォーマンス改善を行いました。

さらにこうした指標は実際のユーザーの環境で得られた値を一定量集めることも大事なので、集計結果をGoogle Analyticsに送信しています。そうすることで、GAを使いなれたプロに分析をお任せすることもできますからね。

そうした経緯は弊社技術ブログの記事に詳しく書かれています。

白石: なるほど…パフォーマンス改善がビジネスに寄与するという道筋を立てることで、パフォーマンス改善が業務として意味にあるものになるわけですね。

あほむ: そうですね。パフォーマンス改善とビジネスが両輪としてうまく回るためにも、やはり様々なパフォーマンス指標や計測が大事になってきます。

指標は他にもFirst Contentful Paint （コンテンツが表示され始めた時）や First Meaningful Paint （ユーザーに意味のある表示になったとき）など様々なものが考案され、実装も行われています。よければそういう話をまとめた私のブログ記事も見てみてください。

白石: なるほど、今日は貴重なお話をお聞かせいただきありがとうございました！HTML5 Conferenceでのセッションも楽しみにしています。