Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
モダンWebパフォーマンス2020_株式会社ニジボックス Yuki Irisawa
Search
株式会社NIJIBOX
December 18, 2020
Programming
9
14k
モダンWebパフォーマンス2020_株式会社ニジボックス Yuki Irisawa
リクルートグループ主催!『大規模メディアにおけるWeb開発の最前線』
https://business-and-creative.connpass.com/event/188628/
株式会社NIJIBOX
December 18, 2020
Tweet
Share
More Decks by 株式会社NIJIBOX
See All by 株式会社NIJIBOX
Tableau トレーニング【株式会社ニジボックス】
nbkouhou
0
32k
Adobe Analytics勉強会の種類とレベル分け【株式会社ニジボックス】
nbkouhou
0
53
Adobe Analytics入門講座【株式会社ニジボックス】
nbkouhou
0
32k
[Adobe Analytics]主な役割と必要な知識【株式会社ニジボックス】
nbkouhou
0
60
SQL初級中級_トレーニング【株式会社ニジボックス】
nbkouhou
0
32k
アクセシビリティ_株式会社ニジボックス Katsuhito Karube
nbkouhou
1
10k
SUUMOでのパフォーマンス_株式会社ニジボックス Satoshi Arai
nbkouhou
1
9.5k
非機能要件を文化に _株式会社ニジボックス Yosuke Furukawa
nbkouhou
0
360
カスタマージャーニーマップを共通言語に、UXリサーチをアウトプットにつなげたい話_Qrio株式会社 神谷 郁
nbkouhou
0
2.4k
Other Decks in Programming
See All in Programming
楽して成果を出すためのセルフリソース管理
clipnote
0
200
個人開発で徳島大学生60%以上の心を掴んだアプリ、そして手放した話
akidon0000
1
170
ぬるぬる動かせ! Riveでアニメーション実装🐾
kno3a87
1
230
print("Hello, World")
eddie
2
530
より安全で効率的な Go コードへ: Protocol Buffers Opaque API の導入
shwatanap
3
850
「手軽で便利」に潜む罠。 Popover API を WCAG 2.2の視点で安全に使うには
taitotnk
0
880
JSONataを使ってみよう Step Functionsが楽しくなる実践テクニック #devio2025
dafujii
1
650
Platformに“ちょうどいい”責務ってどこ? 関心の熱さにあわせて考える、責務分担のプラクティス
estie
1
250
半自動E2Eで手っ取り早くリグレッションテストを効率化しよう
beryu
1
200
rage against annotate_predecessor
junk0612
0
170
250830 IaCの選定~AWS SAMのLambdaをECSに乗り換えたときの備忘録~
east_takumi
0
400
デザイナーが Androidエンジニアに 挑戦してみた
874wokiite
0
590
Featured
See All Featured
Being A Developer After 40
akosma
90
590k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.1k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Unsuck your backbone
ammeep
671
58k
Bash Introduction
62gerente
615
210k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.9k
Statistics for Hackers
jakevdp
799
220k
Navigating Team Friction
lara
189
15k
Music & Morning Musume
bryan
46
6.8k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Writing Fast Ruby
sferik
628
62k
Six Lessons from altMBA
skipperchong
28
4k
Transcript
2020/12/10 @ Business & Creative
• Sier 営業 → HTMLコーダー → フロントエンドエンジニア(今ここ) • 一生懸命生きています
• 最近自動カーテン開け機を買いました おすすめです 自己紹介
今開発しているサービスについて • ホットペッパービューティーコスメ (以下コスメ) • 日本一速いサイト作ってます • コスメの口コミサービス (いわゆるUGCというやつ)
• 2020年2月に web 版リリース ◦ FE 5人で立ち上げから初期リリースまでやりきりました ◦ 今もその5人で運用しています • 日本一速いサイト作ってます
None
なぜ速さにこだわるのか
速い方がいいに決まってるからだろ
None
真面目に説明すると
• 圧倒的にスマホユーザー多し ◦ 基本的にPCよりも低スピード ◦ 月末の帯域制限に引っかかりがち、軽くてサクサク であることが重要 • 通勤中や休憩中などの、ちょっとした空き時
間によく見られている ◦ 電車内や地下鉄の駅など、電波状況が良好でな い環境での閲覧も多い ◦ すきま時間にサクッと見たいという需要が高いの で、初期表示が遅いと簡単に離脱されちゃう おれたちはなぜ速さにこだわるのか
おれたちはなぜ速さにこだわるのか • ローディングスピードは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
おわかりいただけただろうか
最高のUXのため 表示速度を爆速にしたい そしたら競合にも勝てるはず
快適なUXをお届けするための技術選定
超雑版コスメのシステム構成(フロントエンド) ユーザー CDN origin 速すぎて 止まって見える
None
• Google が推奨している、ウェブサイト閲覧を高速 化することに特化した web コンポーネントのフ レームワーク • 速度低下の原因になるコードを書かせないような 仕組みになっている
◦ JavaScript は書けない(代わりに多様な AMP コンポー ネントが用意されている) ◦ CSS は 75KB 以下に制限されている ◦ 分析/広告タグは許可されたもののみ利用可能 AMPとは何かをざっくり説明する AMP コンポーネントでここまで表現できちゃう
よっしゃ、 AMPにしたから むっちゃ速くなるわ
AMP だから速いという誤解 • (再掲)速度低下の原因になるコードを書かせないような仕組み ◦ 速くするっていうより遅くしないという方が正しい • 逆に言えば、速度低下の原因となるようなコードが含まれていたら AMP
だけど遅 いってことも十分にあり得る 速度低下を引き起こす原因(例) 無駄にサイズの大きい画像 / ネストが深すぎるDOM / 最適化されていないcss / 日本語 web font
AMP 化だけで満足せず、地道に頑張ってきた
AMP 化だけで満足せず、地道に頑張ってきた
AMP に PR 出してもらったりもした ちゃんと話すと長くなるので詳細 な説明は割愛しますが、AMP コ ンポーネント側の問題を古川さ んに直してもらったこともありまし た
他にも泥臭い改善の取り組みをたくさん重ねてきた 全部話してる時間はないので、これらの素晴らしいブログをみてください AMP におけるパフォーマンス改善 計測・検討・対処のプロセスでWebサービスのパフォーマンスを改善する
おわかりいただけただろうか
テクいこともやってるけど、 割と単純で地道な作業の積み重ねで めっちゃ速いサイト作ってる
それはつまり
パフォーマンス改善が 施策ではなく文化になっている ということ
パフォーマンス改善が文化になっている組織 • web FE 5人全員が、パフォーマンス最適化の重要 性をちゃんと理解してる ◦ 高いパフォーマンスを維持し続けるためにどうすべきかを 常に考えながら日々の機能開発に取り組んでいる
• FEだけじゃできないことも、BEとチームになって一 緒に解決している • ディレクターやデザイナーも、パフォーマンスの大切 さをわかってくれてる ◦ ページ速度を極度に損なう施策はやらないという意思を 持ってくれている
全員が超優秀なエンジニアだから 上手くいったって話でしょ? そんなん再現性ないわ〜
全員が優秀なエンジニア? FE 5人の内訳はこんな感じ リーダー: すごい サブリーダー: すごい わたし: マークアップ出身 実務React初めて
同僚Y子: マークアップ出身 実務Reactちょびっと オラッッ もっと 速く!!! 優秀なエンジニアに囲まれてるというのは否定しません 赤ちゃんエンジニア (参画当時)
全員がリードエンジニアじゃなくても ちゃんと品質が担保できて パフォーマンスに気を配れる 仕組みづくりができている
全員がリードエンジニアじゃなくても ちゃんと品質が担保できて パフォーマンスに気を配れる仕組み
とは
計測を習慣化する
• Lighthouse とは…… ◦ パフォーマンスやアクセシビリティ、SEOなどの観点 から web ページの品質を評価してくれるツール •
CI で計測してるので、機能開発によってスコア が落ちたらすぐに気付くことができる ◦ 自動化することで日々の改善活動に組み込む Lighthouse CI
開発効率を上げて 非機能要件に注力しやすくする
こだわりの詰まったDX • renovate によるパッケージ更新管 理の自動化 • reg-suit によるビジュアルリグレッ ションテスト •
これらに加えて、型チェックやテスト なども全部CIで実行 • 開発スタートから1年経った今も継 続してDX改善が行われている
必要とあらば OSS に PR を出す • コスメでは計測上の理由からあえて invalid な AMP
を使っている • そのため Next.js 側の amp-validator に引っかかってエラーになってしまっ ていた • 古川さんのPRのおかげで、カスタム の validator を使えるようになりDXが また向上した
メンバー全員の能力を 一定以上に引き上げる
みんモブ会(みんなでモブプロ) • PRの内容をみんなに説明してその場で レビューしてもらったり • 難しい実装を行ったらその内容を他のメ ンバーに共有したり • エラーの内容やライブラリの新機能につ いてみんなに解説したり
• 詰まってること、迷ってることをみんなに 相談したり 週2で定期開催してる
• バックエンド側のテーマについて話すけ ど、基本的にFEも参加する • FEじゃわからないことなどを相談したり、 教えてもらったりもする • 次期案件の仕様を一緒に検討したりもす る バックエンドみんモブもある
わからないことを放置しない仕組みをつくる • 優秀な先輩エンジニアがサクッと実 装してくれた内容は、なんとなーく、 ふんわりとした理解のまま流してしま いがち • 日報FMTに「実はよくわかってないこ と」という欄をつけて運用することで、 全体の理解度を引き上げることがで
きる 実はよくわかっていないことを白状したら、 意外とみんなもわかってなかったことがわかった図
1年続けたらめっちゃ成長した • これはわたしのコーンフレーク 図(古川さんのお話にも出て きた強さグラフ) • 足りない部分は自分で勉強し たり、教えてもらったり、スキ ルつきそうなタスク振っても らったり
• グラフがでかくなるの楽しいか ら頑張れる
パフォーマンスが上がる 定期的なモブプロで 知識の平準化が もたらされる 開発効率を上げて 非機能要件に 注力しやすくする
パフォーマンスが上がる 怒りにうち震えながら 修正する 速度低下要因があると… DOMが 多すぎる 画像が クソデカい CSSに めっちゃ
無駄ある 苦しい もっと速く
None
まとめ
スライド1枚でわかる今日の話の要点 AMP(今日は紹介しきれなかったけど、他にも色々な技術を 使って爆速サイトを作っています) Lighthouse CI をはじめとしたツールで継続を習慣化 終わらないDX改善(renovate や reg-suit の他にも、今日紹介
できなかった細かいものはたくさんある) 習慣化したモブプロ、わからないことをほっとかないチームづく り、レーダーチャートで成長を促す
技術、仕組み、文化 どれが欠けても この結果は出せなかった
ありがとうございました!