Bonfire Frontend #3 に参加してきました（╹◡╹）

BONFIRE LIT
f:id:gachapining:20190128144248j:plain

Bonfire Frontend #3 で ヤフーさんの LODGE へお邪魔してきました！

初 LODGE だったのですが、オープンで遊び心が感じられる自由な雰囲気の空間で、それはもうとても素敵なものでした。ずるいぞ。

さて、今回はブログ枠として参加してきましたので、本記事を書いています。発表スライドは connpass にアップロードされるようなので、 自分が特に印象に残っていることと、その所感を述べます。

最初は、見聞きした内容を中心に要約しようと思いましたが、いざ書き始めてみると、スライドのクローンを錬成している感があり方針転換と相成りました。

Bonfire Frontend #3 パフォーマンス改善

アーキテクチャリニューアルから、考えるフロントエンドとデータモデリング

  • Retty 株式会社: 竹野峻輔
  • slide: https://

皆さんご存知 Retty さんの提供されるサービス Retty のリニューアル(リアーキテクチャ)に関するお話。 今回は具体的なベストプラクティスや、Tips といった話よりは、先を見据えた計画や、チームビルディング、心構えといった話が中心であった。

竹野さんはデータエンジニアとしても活躍されている様子。すごい。

プロダクトだけではなく、チーム自身も作り変える

特に印象に残っているのは、中長期的なパフォーマンス改善においては、 単にプロダクトを作り変えるという意識だけではなく、チーム自身も作り変えていく必要があるという話。

今回登壇された方々は表現は違えど共通して、パフォーマンス改善は(プロダクトの)一生続けるべきものであるという話をしていて、 そのために、継続的に改善を続けられるチーム作り(仕組み)が重要であると。

モノリシックからマイクロサービスへ

元々モノリシックに構築されているサービスをマイクロサービス化しているという話では、 モジュール化する上でどこに境界を引くかが設計の争点となるが、 この境界は横断的なチームコミュニケーションによって、必要に応じて各モジュールの責任範囲を改め、柔軟に変更しているという話であった。

これについて、コミュニケーションを綿密にとることが重要だという話に異論はないが、 それでも Retty ほど利用ユーザの多い商用サービスで、インパクトの大きい変更をガシガシ加えることは、それなりにリスクがあるように感じた。

先端を行く B2C サービスではそのくらいのアジリティが求められているということだろうか。 もしくは、production deploy 前の状況であったとか・・・？

チームで技術を選定する

リアーキテクチャにおいて、選定する技術は特定の領域のメンバーが決めるのではなく、 関わるメンバー全体で決定し、個々人が納得感を得ることが重要であるという話。

これには同意見でありながらも、現実では割とトップダウンで自分が選んでしまうことが多く、 仮に形式的であっても、議論する場を設けて決定した方が良いのかも、と反省。

形式的という表現をしたのは、意見を変える気がないという意味ではなく、 フロント経験者が少なく、未経験者や外注さんと組むことが多いため・・・。

また、その具体例として、クライアントとサーバ間の通信において、GraphQL を採用したという話は興味深かった。 確かに、チャレンジングな技術選択でノウハウを持つ人は少ない状況だと思うので、選定に納得していないと辛いフェーズは出てくるように感じた。

一休.com のフロントエンドパフォーマンス改善

今回は、ウェブフロントエンド全体における、マクロな観点におけるパフォーマンス改善の話。ベストプラクティスといった話から昨今の現状や経験談など、幅広く濃い内容で聴き応えがあった。

また、もう少しミクロな観点である、コード改善や Tips といった話については、 前回に話したスライド を参照とのこと。

一休.com と一休コンシェルジュ

パフォーマンスの計測

「推測するな。測定せよ。」とは良くいったもので、十分理解しているつもりではあったが、サイトの形態によって、どのメトリクスが重要視されるかというのは深く考えたことがなく頷くばかりであった。 (ECサイト、メディアサイトであればロード時間、ゲームであればプレイ中の FPS 維持など)

さて、自分の直近の仕事であった B2B サービスではどうかと思考を巡らせてみると、初回読み込み時間は重要でユーザ体験に直結はするが、離脱する種のサービスではないので、頻繁に利用する機能のパフォーマンス改善がよりよいユーザ体験に結びつくだろうか。

ただ、これらの改善は求められているわけではないのが現状で、逆に重要だという提案をするにしても、それと利益との相関関係を証明することは難しく、現実的には厳しいところだろう。うーむ。

計測ツール

ツールは多様であるが、Chrome DevTools (audit) を始めとして、そのバックエンドとしては Lighthouse が利用されていることが多いらしい。各人ローカルで DevTools を利用すると環境による影響が出るため、クラウドサービスを利用した方が良いとのこと。

恐らく、サービスであれば CI とも連携しやすく、定常的にパフォーマンスを計測することができるため、導入しない理由はないように感じる。想定外のパフォーマンスデグレードにも早い段階で対応ができそう。

PageSpeed Insight

  • とっつきやすい
  • 下り 1.40Mbps 環境で測定される
    • お昼時の、格安 SIM (4G回線)がこのくらい

WebPageTest

  • とっつきにくいが多機能、上級者向け
  • locaton(region) の変更、繰り返し測定など

余談だが、サイトを探す際に googlability が低く勿体無いと思った。

Lighthouse のスコアと指標

  • Lighthouse のスコアは他社サイトとの比較に便利
    • EC サイトは目標 50〜
    • メディアサイトは目標 70〜
  • 自社サービスのチューニングの際は指標を見るべき
    • スコアは算出方法が変わることがある
    • 主要導線である複数ページを対象とする

この辺りも肌感が全く無かったため、実際運用されているサービスの体感速度とそれに対応するスコア感の話は非常に参考になった。

パフォーマンスの最適化戦略

かなり省いているので詳細はスライド参照。

遅い要素を減らしていくのが基本方針。

一休.com / 一休コンシェルジュ、共に画像リソースが非常に多いため、この最適化による影響が大きいという話であった。 ツールとしては imgix を利用して画像自体のサイズを削減すると同時に、ファーストビューに入らない画像は lazy load とする。

メディアサイトは Fastly のキャッシュ戦略が特に有効であるが、EC サイトは性質上長くキャッシュをもたせることができないデータも多いため、(価格、ユーザ情報など)メディアサイトに比べると TTFB が落ちるのは一般的。

全く関係ないが、"Above the Fold" という表現を初めて知った。ファーストビューと同じ？意味合いではあるが、かっこいいとおもいました。(小並感)

JAMSTACK と SEO

JAMSTACK というキーワードは初めて聞いたのだが内容としては馴染み深いもので、ざっくりといえば、ウェブアプリは SSR しないプリビルドされた SPA を利用する方式で、これは静的データであることから CDN で効果的にキャッシュできるという話である。(た、たぶん)

ただし、当然 SEO については色々と検討が必要になり、現在は Google bot 対策として、dynamic rendering で Rendertron を実験中とのこと。

この辺の用語もわからず調べたのだが、dynamic rendering とは、サーバサイドで Google bot からのリクエストの場合にのみ、事前にレンダリング済みの専用の HTML をレスポンスに返すという方式らしい。

当然この HTML は本来のウェブアプリ(SPA)と同等の内容が期待され、あからさまに異なる HTML を用意している場合はクローキングとして扱われてペナルティを受けることがあるそうだ。

個人的には、Google 側が「あからさまに異なる」という判定をどう行っているのか気になった。Chrome 41 相当の Google bot とは異なる一般ユーザと区別がつかない bot が存在してクローリングしているのだろうか。

その他所感

パフォーマンス改善にガチに取り組む姿勢に驚いた。パフォーマンス改善を目的としてサービスの構成から作り変える可能性も含めて検証し、積極的に production に取り込んでいくという意思を感じた。

私自身は B2B サービスの請負い開発が多いためか、銘打ってパフォーマンスが重要視されることはほぼなく、姿勢の違いに衝撃を受けた。

恐らく、B2C サービス(特に ECサイト)の世界では、パフォーマンス改善が利益に直結する世界であるため、こういった姿勢に差が生まれるような気がした。

実際に、一休.com 開いて、これだけ画像が多いのに確かにはえー、と盛り上がったりした。

パフォーマンス改善の具体例とサービスへの売上貢献

  • ヤフー株式会社: 笹原翼
  • slide: https://

自社サービスであるヤフーショッピングに対して、なぜパフォーマンスチューニングを行い、どう取り組み、どう成果がでたか、その一連の流れを丁寧にかつ、面白く話をしていただいた。また、参加者がすぐに実務に適用できるような Tips やチェックシートまでもが整理されていて、即効性が高く非常に参考になった。

パフォーマンスチューニングに取り組んだ結果としては CVR が 110% 向上したそうだ。

パフォーマンス改善のリソースを確保する

明確な回収見込みが提示できないとリソースを割くことが難しいという話。よくあるジレンマだと思っているが、ヤフーさん程の体力があっても変わらないというのは意外であった。

A/B テストによって、ページの初回ロード時間と CVR、各種指標への相関を示すことで、実際に偉い人を説得し、リソースを確保したそうだ。確かに、これ以上ない仕事の運び方だと思う。

ファーストビューの9割表示を指標とした

これが興味深かった。

先の一休.com さんの例でいうと Lighthouse の何かしらの指標を目標としておいていた(と記憶している)が、ヤフーさんの場合はエンドユーザ視点で、9割表示されれば体験を阻害せずサービスとして十分機能している状態であるという判断したのだろう。

私の社内の話だが、ページを読み込んだ後に、投機的にリンクの先読みを行う仕組みがあり、計測結果としては先読み完了後までの時間が得られてしまい実際の体験に即していないという悩みがあった(らしい)

その点でも、ファーストビューの表示率という観点は良いもののように思えた。

計測ツールは SpeedCurve を利用

  • 強豪と比較がしやすい
  • 継続的に確認してグラフ化する
  • 有償だけど比較的手頃
  • キャプチャを目視でグラフを見やすく加工している

ヤフーショッピングの場合は明確な競合があり、リアルタイムに競合と指標を比較し続けることができるという機能はとてもマッチしていたように感じた。

ただ、それ程高価ではないとはいえ、有償ツールで維持コストがかかるため、継続的に結果を出していかないと稟議の説明が苦しくなるのかな、とか思った。(弊社視点)

レスポンスの圧縮形式を gzip -> brotli へ変更

あくまで、紹介されていた施策のうちの1つでありこれ単体で大きな効果があったわけではなかったようだが、そもそも brotli という圧縮形式を知らなかった。ググってみたところ、Google の開発した近代的な圧縮フォーマットで、gzip に比べて2割くらい軽くなる傾向にあるという。Encode/Decode にかかる時間は若干増加するという情報もあるが、込みでスループットが向上することは多いようだ。

私が聞いたことすらなかったため、ブラウザが対応しているものなのかと疑問に思ったのだが、全てのブラウザは余裕で対応していた。(IE からは目を背けながら)

https://caniuse.com/#search=brotli

リクエストヘッダの Accept-Encoding では 'br' が追加されるようだ。

その他所感

CVR の計測について気になるのだが、サービス自体、目まぐるしく変わるであろうコンテンツと、加えて、運用としての様々な試みや、機能追加も色々とあるはずだが、パフォーマンスチューニングのみの成果を測定するというのはできるものなのだろうか。

チューニング期間全体の上がり幅を見るのではなくて、個々の施策の成果を合計値で見るとか？

あと、スライドのクオリティがとても高かった。こういったデザイン的にも内容的にも洗練されたスライドってどうやって作っているんだろう。エンジニアソロで完結しているように思えないのでとても気になる。

全体の所感

非常に勉強になった。

いずれも初回読み込み速度の短縮を指標として置いていたが、このチューニングを考えると、WebFrontend というよりは、もっと広くサービス全体の構成を抑えた上で、技術スタックやその特性を1つ1つ丁寧に理解していないと、適切な考察や改善策を打ち出すことが難しく、広く深い知識が求められるように感じた。

道中にも少し書いたが、私自身は B2B 向けの請負ウェブアプリの開発が多く、仕事として既存サービスに対するパフォーマンスチューニングが求められる機会というのは少ない現状ではあるが、新たにゼロベースでサービスの設計から入る機会は多いため、これらのナレッジを生かしていきたい。