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

by 株式会社NIJIBOX

Slide 1

Slide 1 text

2020/12/10 @ Business & Creative

Slide 2

Slide 2 text

● Sier 営業 → HTMLコーダー → フロントエンドエンジニア（今ここ）   ● 一生懸命生きています   ● 最近自動カーテン開け機を買いましたおすすめです   自己紹介 

Slide 3

Slide 3 text

今開発しているサービスについて  ● ホットペッパービューティーコスメ（以下コスメ）  ● 日本一速いサイト作ってます  ● コスメの口コミサービス（いわゆるUGCというやつ）   ● 2020年2月に web 版リリース   ○ FE 5人で立ち上げから初期リリースまでやりきりました  ○ 今もその5人で運用しています  ● 日本一速いサイト作ってます 

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

なぜ速さにこだわるのか 

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

真面目に説明すると 

Slide 9

Slide 9 text

● 圧倒的にスマホユーザー多し  ○ 基本的にPCよりも低スピード   ○ 月末の帯域制限に引っかかりがち、軽くてサクサクであることが重要  ● 通勤中や休憩中などの、ちょっとした空き時間によく見られている  ○ 電車内や地下鉄の駅など、電波状況が良好でない環境での閲覧も多い   ○ すきま時間にサクッと見たいという需要が高いので、初期表示が遅いと簡単に離脱されちゃう   おれたちはなぜ速さにこだわるのか 

Slide 10

Slide 10 text

おれたちはなぜ速さにこだわるのか  ● ローディングスピードは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  

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

● Google が推奨している、ウェブサイト閲覧を高速化することに特化した web コンポーネントのフレームワーク  ● 速度低下の原因になるコードを書かせないような仕組みになっている  ○ JavaScript は書けない（代わりに多様な AMP コンポーネントが用意されている）   ○ CSS は 75KB 以下に制限されている   ○ 分析/広告タグは許可されたもののみ利用可能   AMPとは何かをざっくり説明する  AMP コンポーネントでここまで表現できちゃう  

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

AMP だから速いという誤解  ● （再掲）速度低下の原因になるコードを書かせないような仕組み  ○ 速くするっていうより遅くしないという方が正しい   ● 逆に言えば、速度低下の原因となるようなコードが含まれていたら AMP だけど遅いってことも十分にあり得る  速度低下を引き起こす原因（例）    無駄にサイズの大きい画像 / ネストが深すぎるDOM / 最適化されていないcss / 日本語 web font  

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

それはつまり 

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

パフォーマンス改善が文化になっている組織  ● web FE 5人全員が、パフォーマンス最適化の重要性をちゃんと理解してる  ○ 高いパフォーマンスを維持し続けるためにどうすべきかを常に考えながら日々の機能開発に取り組んでいる   ● FEだけじゃできないことも、BEとチームになって一緒に解決している  ● ディレクターやデザイナーも、パフォーマンスの大切さをわかってくれてる  ○ ページ速度を極度に損なう施策はやらないという意思を持ってくれている 

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

全員が優秀なエンジニア？  FE 5人の内訳はこんな感じ  リーダー: すごい  サブリーダー: すごい  わたし: マークアップ出身  実務React初めて  同僚Y子: マークアップ出身  実務Reactちょびっと  オラッッ  もっと  速く！！！  優秀なエンジニアに囲まれてるというのは否定しません   赤ちゃんエンジニア  （参画当時） 

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

とは 

Slide 33

Slide 33 text

計測を習慣化する 

Slide 34

Slide 34 text

● Lighthouse とは……  ○ パフォーマンスやアクセシビリティ、SEOなどの観点から web ページの品質を評価してくれるツール   ● CI で計測してるので、機能開発によってスコアが落ちたらすぐに気付くことができる  ○ 自動化することで日々の改善活動に組み込む   Lighthouse CI 

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

こだわりの詰まったDX  ● renovate によるパッケージ更新管理の自動化  ● reg-suit によるビジュアルリグレッションテスト  ● これらに加えて、型チェックやテストなども全部CIで実行  ● 開発スタートから1年経った今も継続してDX改善が行われている 

Slide 37

Slide 37 text

必要とあらば OSS に PR を出す  ● コスメでは計測上の理由からあえて invalid な AMP を使っている  ● そのため Next.js 側の amp-validator に引っかかってエラーになってしまっていた  ● 古川さんのPRのおかげで、カスタムの validator を使えるようになりDXがまた向上した 

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

みんモブ会（みんなでモブプロ）  ● PRの内容をみんなに説明してその場でレビューしてもらったり  ● 難しい実装を行ったらその内容を他のメンバーに共有したり  ● エラーの内容やライブラリの新機能についてみんなに解説したり  ● 詰まってること、迷ってることをみんなに相談したり  週2で定期開催してる 

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

1年続けたらめっちゃ成長した  ● これはわたしのコーンフレーク図（古川さんのお話にも出てきた強さグラフ）  ● 足りない部分は自分で勉強したり、教えてもらったり、スキルつきそうなタスク振ってもらったり  ● グラフがでかくなるの楽しいから頑張れる 

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

まとめ 

Slide 47

Slide 47 text

スライド1枚でわかる今日の話の要点  AMP（今日は紹介しきれなかったけど、他にも色々な技術を使って爆速サイトを作っています） Lighthouse CI をはじめとしたツールで継続を習慣化終わらないDX改善（renovate や reg-suit の他にも、今日紹介できなかった細かいものはたくさんある）習慣化したモブプロ、わからないことをほっとかないチームづくり、レーダーチャートで成長を促す

Slide 48

Slide 48 text

技術、仕組み、文化  どれが欠けても  この結果は出せなかった 

Slide 49

Slide 49 text

ありがとうございました！ 