FE エンジニアは Web Platform 動向を追うべきか？

「TECH BATON in 東京 〜うちのフロントエンド進化のツボ ！コード長持ちのための技術〜」での発表資料です。

Slidev: https://progfay.github.io/should_track_web_platform_trends/

Transcript

1. FE エンジニアは Web Platform 動向を追うべきか？ 2026.01.20 | Findy TECH BATON | @progfay
2. Name: 眞野 ま の 隼輔 しゅんすけ @progfay Web Frontend Engineer 趣味で Web の動向を追っかけている トラックボール付き Cornix を熱望している
3. Web Platform の動向、追ってますか？
4. Web Platform 動向って何だっけ？ ※ 個人的な定義です。 Proposal: どのような機能が提案されているのか Discussion: どのような議論がされているか Shipment: どのような機能がブラウザに実装されるか プロダクト開発に一番影響するのは Shipment
5. Shipment 新しく公開された API などがプロダクトで使える！
6. Major Browsers Apple Safari (macOS / iOS) Google Chrome (desktop / Android) Microsoft Edge (desktop) Mozilla Firefox (desktop / Android) etc… これらの Shipment をそれぞれ追うのは大変…
8. What’s Baseline? ref. Baseline (compatibility) - Glossary | MDN Baseline （ベースライン）は、ブラウザー間で動作するウェブプラットフォームの機能を確認します。 Baseline は、サイトの訪問者に互換性の問題を引き起こす可能性が低くなった時期を示すことで、その機能を使用す るタイミングを決定するのに役立ちます。 ある機能がどれだけのブラウザで利用可能かを測る指標
9. Baseline Status ref. Baseline (compatibility) - Glossary | MDN
10. どのタイミングから使う？ 一部の Major Browser でのみ Ship された 流石に時期尚早感がある 全 Major Browser で Ship された 「最新 ver. に更新して」が可能に とはいえ、まだ多くの環境では使えない 全 Major Browser で Ship されてだいぶ経った どれくらい時間が経てばいい？ 古いブラウザはサポートしない？
11. 基準を定めている現場もあるかも サポートするブラウザについて公開していたり 内部では、より広いブラウザをサポートしようとしていたり Browserslist { "browserslist": [ "last 1 version", "> 1%", "not dead" ] }
12. どうやって基準を設定する？ プロダクトの特性を見極めて設定するのがベスト ユーザーが使うブラウザと version の分布は？ 未実装のブラウザではどれくらい困る？ etc… でも見極めってめっちゃ難しい リリース前では判断するための情報が足りない そもそもあんまり詳しくない ( ぶっちゃけめんどくさい…)
14. Baseline: Newly → Widely Newly Available になってから 30 ヶ月後に Widely Available になる。 ref. ベースラインの定義の更新 | Blog | web.dev この広く利用されている線が、すべての人にとって正確であるとは限らないことは承知しています。 しかし、ブラウザ バージョンの導入に関する利用可能なデータを調べたところ、 ほとんどの機能は、世界中の約 95% のユーザーが利用できるようになるまでに 30 か月もかからないことがわかりました。 この期間よりもずっと早 く機能をご使用になっても問題ないかもしれませんが、相互運用から 30 か月が経過すると、その機能を使用できなく なる可能性は低くなります。
15. どうやって Web Platform 動向を追えばいい？ プロダクト開発においては Baseline を追うだけでも十分 Baseline 2025 November 2025 Baseline monthly digest New to the web platform in December
16. Baseline 以外は追わなくて良い？ Shipment には 3 パターンある 1. プロダクトに影響しない Shipment 2. 対応すると嬉しい Shipment Baseline を追うことで発見できる 3. 対応しないとヤバい Shipment Breaking Change: 3rd Party Cookie Deprecation ( SameSite=Lax ) Security Updates: Spectre / Meltdown etc…
17. Don’t Break the Web ref. ウェブ標準モデル - ウェブ開発の学習 | MDN しかし実際には Breaking Change が起きる これは「ユーザーの安全性」を毀損すると判断された場合に起きる Breaking Change は十分に議論された上で Ship される オープンなウェブ標準の周りで耳にするもう一つの言葉は「ウェブを壊さない」です。 この考えは、導入される新しいウェブ技術は、過去に行われたものが下位互換性を持ち（つまり、古いウェブサイト も引き続き動作する） 、上位互換性がある（将来の技術は、現在あるものと互換性がある）べきだというものです。
18. Web Platform 動向って何だっけ？ ※ 個人的な定義です。 Proposal: どのような機能が提案されているのか Discussion: どのような議論がされているか Shipment: どのような機能がブラウザに実装されるか 再掲 Proposal, Discussion から Web Platform が進む方向性が予測できる
19. まとめ Web Platform 動向はまず Baseline を追うところから始めよう Baseline 2025 November 2025 Baseline monthly digest New to the web platform in December 新機能を利用するかの判断基準 プロダクトの特性を見極めて設定するのがベスト 大変なら Baseline Widely Available を活用するのも良い Proposal や Discussion も追うと Web Platform が進む方向性が予測できる @progfay はこれを趣味として楽しんでいます！
20. おまけ: @progfay の新機能利用基準 基本戦略: 不要な挑戦はしない Feature Detection での分岐は fallback との二重管理になってしまう Transpile や Polyfill で Bundle Size 増やしてもユーザーは嬉しくない 開発効率の向上やバグの低減につながるなら要検討 リリースした後でも、使えないユーザーが多そうなら修正する Array.prototype.at や OffscreenCanvas は Widely Available しかし Sentry などに "OffscreenCanvas is not defined" などのエラーが上がってくる 数が多そうならユーザーの不利益になるので即修正 新しい機能を使いたい気持ちをグッと抑えて Widely Available を虎視眈々と待っている field-sizing: content と Navigation API 早く来てくれ… ！