Save 37% off PRO during our Black Friday Sale! »

モダンWebパフォーマンス2020_株式会社ニジボックス Yuki Irisawa

モダンWebパフォーマンス2020_株式会社ニジボックス Yuki Irisawa

リクルートグループ主催!『大規模メディアにおけるWeb開発の最前線』
https://business-and-creative.connpass.com/event/188628/

1623dd1adf096ba35ba33727d933e14c?s=128

株式会社NIJIBOX

December 18, 2020
Tweet

Transcript

  1. 2020/12/10 @ Business & Creative

  2. • Sier 営業 → HTMLコーダー → フロントエンドエンジニア(今ここ) 
 • 一生懸命生きています

    
 • 最近自動カーテン開け機を買いました おすすめです 
 自己紹介

  3. 今開発しているサービスについて
 • ホットペッパービューティーコスメ (以下コスメ)
 • 日本一速いサイト作ってます
 • コスメの口コミサービス (いわゆるUGCというやつ) 


    • 2020年2月に web 版リリース 
 ◦ FE 5人で立ち上げから初期リリースまでやりきりました
 ◦ 今もその5人で運用しています
 • 日本一速いサイト作ってます

  4. None
  5. なぜ速さにこだわるのか


  6. 速い方がいいに決まってるからだろ


  7. None
  8. 真面目に説明すると


  9. • 圧倒的にスマホユーザー多し
 ◦ 基本的にPCよりも低スピード 
 ◦ 月末の帯域制限に引っかかりがち、軽くてサクサク であることが重要
 • 通勤中や休憩中などの、ちょっとした空き時

    間によく見られている
 ◦ 電車内や地下鉄の駅など、電波状況が良好でな い環境での閲覧も多い 
 ◦ すきま時間にサクッと見たいという需要が高いの で、初期表示が遅いと簡単に離脱されちゃう 
 おれたちはなぜ速さにこだわるのか

  10. おれたちはなぜ速さにこだわるのか
 • ローディングスピードはUXとSEOの要
 ◦ UXにおいてユーザーが重視する要素の75%はローディン グにかかるスピード(※1)
 ◦ ページが遅ければ遅いほど直帰率は悪化する (※2)
 •

    ローディングスピードはGoogleの検索順位に影響 する
 ◦ 後発サービスとして、競合よりも検索順位を上げていか ないと認知度を上げられない 
 ※1 https://www.awwwards.com/brainfood-mobile-performance-vol3.pdf ※2 https://developers-jp.googleblog.com/2017/03/new-industry-benchmarks-for-mobile-page-speed.html 

  11. おわかりいただけただろうか


  12. 最高のUXのため
 表示速度を爆速にしたい
 そしたら競合にも勝てるはず


  13. 快適なUXをお届けするための技術選定


  14. 超雑版コスメのシステム構成(フロントエンド)
 ユーザー
 CDN
 origin
 速すぎて
 止まって見える


  15. None
  16. • Google が推奨している、ウェブサイト閲覧を高速 化することに特化した web コンポーネントのフ レームワーク
 • 速度低下の原因になるコードを書かせないような 仕組みになっている


    ◦ JavaScript は書けない(代わりに多様な AMP コンポー ネントが用意されている) 
 ◦ CSS は 75KB 以下に制限されている 
 ◦ 分析/広告タグは許可されたもののみ利用可能 
 AMPとは何かをざっくり説明する
 AMP コンポーネントでここまで表現できちゃう 

  17. よっしゃ、
 AMPにしたから
 むっちゃ速くなるわ


  18. AMP だから速いという誤解
 • (再掲)速度低下の原因になるコードを書かせないような仕組み
 ◦ 速くするっていうより遅くしないという方が正しい 
 • 逆に言えば、速度低下の原因となるようなコードが含まれていたら AMP

    だけど遅 いってことも十分にあり得る
 速度低下を引き起こす原因(例)
 
 無駄にサイズの大きい画像 / ネストが深すぎるDOM / 最適化されていないcss / 日本語 web font 

  19. AMP 化だけで満足せず、地道に頑張ってきた


  20. AMP 化だけで満足せず、地道に頑張ってきた


  21. AMP に PR 出してもらったりもした
 ちゃんと話すと長くなるので詳細 な説明は割愛しますが、AMP コ ンポーネント側の問題を古川さ んに直してもらったこともありまし た


  22. 他にも泥臭い改善の取り組みをたくさん重ねてきた
 全部話してる時間はないので、これらの素晴らしいブログをみてください
 
 AMP におけるパフォーマンス改善
 計測・検討・対処のプロセスでWebサービスのパフォーマンスを改善する


  23. おわかりいただけただろうか


  24. テクいこともやってるけど、
 割と単純で地道な作業の積み重ねで
 めっちゃ速いサイト作ってる


  25. それはつまり


  26. パフォーマンス改善が
 施策ではなく文化になっている
 ということ


  27. パフォーマンス改善が文化になっている組織
 • web FE 5人全員が、パフォーマンス最適化の重要 性をちゃんと理解してる
 ◦ 高いパフォーマンスを維持し続けるためにどうすべきかを 常に考えながら日々の機能開発に取り組んでいる 


    • FEだけじゃできないことも、BEとチームになって一 緒に解決している
 • ディレクターやデザイナーも、パフォーマンスの大切 さをわかってくれてる
 ◦ ページ速度を極度に損なう施策はやらないという意思を 持ってくれている

  28. 全員が超優秀なエンジニアだから
 上手くいったって話でしょ?
 そんなん再現性ないわ〜


  29. 全員が優秀なエンジニア?
 FE 5人の内訳はこんな感じ
 リーダー: すごい
 サブリーダー: すごい
 わたし: マークアップ出身
 実務React初めて


    同僚Y子: マークアップ出身
 実務Reactちょびっと
 オラッッ
 もっと
 速く!!!
 優秀なエンジニアに囲まれてるというのは否定しません 
 赤ちゃんエンジニア
 (参画当時)

  30. 全員がリードエンジニアじゃなくても
 ちゃんと品質が担保できて
 パフォーマンスに気を配れる
 仕組みづくりができている


  31. 全員がリードエンジニアじゃなくても
 ちゃんと品質が担保できて
 パフォーマンスに気を配れる仕組み


  32. とは


  33. 計測を習慣化する


  34. • Lighthouse とは……
 ◦ パフォーマンスやアクセシビリティ、SEOなどの観点 から web ページの品質を評価してくれるツール 
 •

    CI で計測してるので、機能開発によってスコア が落ちたらすぐに気付くことができる
 ◦ 自動化することで日々の改善活動に組み込む 
 Lighthouse CI

  35. 開発効率を上げて
 非機能要件に注力しやすくする


  36. こだわりの詰まったDX
 • renovate によるパッケージ更新管 理の自動化
 • reg-suit によるビジュアルリグレッ ションテスト
 •

    これらに加えて、型チェックやテスト なども全部CIで実行
 • 開発スタートから1年経った今も継 続してDX改善が行われている

  37. 必要とあらば OSS に PR を出す
 • コスメでは計測上の理由からあえて invalid な AMP

    を使っている
 • そのため Next.js 側の amp-validator に引っかかってエラーになってしまっ ていた
 • 古川さんのPRのおかげで、カスタム の validator を使えるようになりDXが また向上した

  38. メンバー全員の能力を
 一定以上に引き上げる


  39. みんモブ会(みんなでモブプロ)
 • PRの内容をみんなに説明してその場で レビューしてもらったり
 • 難しい実装を行ったらその内容を他のメ ンバーに共有したり
 • エラーの内容やライブラリの新機能につ いてみんなに解説したり


    • 詰まってること、迷ってることをみんなに 相談したり
 週2で定期開催してる

  40. • バックエンド側のテーマについて話すけ ど、基本的にFEも参加する
 • FEじゃわからないことなどを相談したり、 教えてもらったりもする
 • 次期案件の仕様を一緒に検討したりもす る
 バックエンドみんモブもある


  41. わからないことを放置しない仕組みをつくる
 • 優秀な先輩エンジニアがサクッと実 装してくれた内容は、なんとなーく、 ふんわりとした理解のまま流してしま いがち
 • 日報FMTに「実はよくわかってないこ と」という欄をつけて運用することで、 全体の理解度を引き上げることがで

    きる
 実はよくわかっていないことを白状したら、 
 意外とみんなもわかってなかったことがわかった図 

  42. 1年続けたらめっちゃ成長した
 • これはわたしのコーンフレーク 図(古川さんのお話にも出て きた強さグラフ)
 • 足りない部分は自分で勉強し たり、教えてもらったり、スキ ルつきそうなタスク振っても らったり


    • グラフがでかくなるの楽しいか ら頑張れる

  43. パフォーマンスが上がる 
 定期的なモブプロで 
 知識の平準化が
 もたらされる
 開発効率を上げて
 非機能要件に
 注力しやすくする


  44. パフォーマンスが上がる
 怒りにうち震えながら
 修正する
 速度低下要因があると…
 DOMが
 多すぎる
 画像が
 クソデカい
 CSSに
 めっちゃ


    無駄ある
 苦しい
 もっと速く

  45. None
  46. まとめ


  47. スライド1枚でわかる今日の話の要点
 AMP(今日は紹介しきれなかったけど、他にも色々な技術を 使って爆速サイトを作っています) Lighthouse CI をはじめとしたツールで継続を習慣化 終わらないDX改善(renovate や reg-suit の他にも、今日紹介

    できなかった細かいものはたくさんある) 習慣化したモブプロ、わからないことをほっとかないチームづく り、レーダーチャートで成長を促す
  48. 技術、仕組み、文化
 どれが欠けても
 この結果は出せなかった


  49. ありがとうございました!