HTML5とか勉強会「Webパフォーマンス」に参加してLTしてきた

LTしてきた。

とりあえず、早口すぎたなと思った。
時間を気にしすぎてしまったかも。

以下勉強会メモ

先入観とバイアスを考慮したWebサイトパフォーマンス改善

先入観とバイアスを考慮したWebサイトパフォーマンス改善 from Yoichiro Takehora

t.co

竹洞さん

日本の現状

世界基準

表示開始時間 0.5秒以内
- Webブラウザ上に最初の1ピクセル目が表示された時間
表示完了時間 2秒以内
- DOM Complete
- DOM処理が終わったタイミング

アメリカのEコマース

(アメリカのEコマース)https://www.dynatrace.com/en/benchmarks/united-states/retail/ns

日本

(日本のWebサイトパフォーマンスランキング)https://www.dynatrace.com/en/benchmarks/japan/retail/ns

どのプロジェクトでも2秒切れば直帰率は50%減る。
CMOがパフォーマンスを確認する
パフォーマンスが売上に直結している。

パフォーマンスは売上を引きずる要員であり、上げる要員ではない

先入観とバイアスだらけ

最低保証パフォーマンスを規定する

寒いマンション

マンションのほうが死亡率が高い。
寒いから。寒さ・暑さ対策といえば断熱材
ほんとに？

遮熱材が入っていない。
コンクリート自体が冷たさを溜め込む冷輻射

我々WEB業界は建築業界を責められない

この辺はたとえの話だったのだが、結構マンション・不動産の詳細な
話に踏み込んでいたので、ちょっと戸惑った。

知らないという事を認識しよう

計測してみるまでは、実際のことはわからない

Don’t guess, measure!

ボトルネックを特定せよ
早まったコンポーネントの最適化

要は何が起きてるかを理解するまでは、最適化や修正をすべきではないってこと。
憶測だけでは状況は悪化する。

非科学的手法は削除する

以下のツールは使うな！

Google PageSpeed Insights
- このツールだけでは高速化できない。このツールはベストプラクティスに合致しているかどうかを判定するツール。業務では使うべきではない
Chromeの開発者ツール。あたりを付けるぶんには問題ない。でもこれは真の値ではない。ユーザーが何秒で見ているかの比率を見るべき
- カバー率の問題。自分のISPがどれほどの範囲をカバーしているのか
- カバー率(時間)の問題。自分が見たタイミングがほんとに正しいか。
- インターネットが変わらないという先入観
Webpage Test
- この計測環境の仕様を知っているか。PCのスペック

ここで使えないと言われているサービスの問題点は、パフォーマンスをある一点からしか計測していないからである。
大事なのはユーザーの環境で実際に何秒かかったのかという一点。

統計学を学ぼう！

統計的な知識でグラフを見ることでほんとに重要なことが読み取れる。

法律での瑕疵担保責任の変化

瑕疵とは？
請負側に品質保証責任があることが明記される。
品質が達成されるまでは無料で働かなければならない。

仕様の実現から目的の実現へ

今まで
ソフトウェアはPL法の対象にならない。ハードウェアは対象

これから
ソフトウェアの請負も品質保証書が必要になる。

つまりクライアントの目的（パフォーマンスも含む）が達成されない場合、損害賠償の可能性がある。

まとめ

高速化するときには先入観で見ない。
お金をかけてでも、製造業のような品質保証をする。

まあまあ最近のパフォーマンスAPIなど

yakura @myasaka

最近みたクライアントサイドの話

jsの比重が大きくなっている。48%ほど

パフォーマンスまわりの仕様

計測関連のAPI
遅くさせないための仕組み
スケジューリング

計測関連

User Timing

Safariにそろそろ来そう…?

Performance Observer

(使い方)https://developers.google.com/web/updates/2016/06/performance-observer

エントリのタイプもこれから増えそう

Long Tasks

長くかかったタスクを検出(50ms以上とか)

First Paint

適切なFirst Paintがどこなのか

FirstContentPaint
FirstMeaningfulPaint

人間の体感的なメトリクス

遅くさせないための仕様

Intersection Observer

scroll と getBoundingClientRectの組合せはおそい！

そこでIntersectionObserver。表示範囲との交差を検出して領域判定を必要としない。
LazyLoadingとかにも使える

CSSからのアプローチ

position:sticky

ある程度までスクロールすると、要素がfixedになる

CSS Contained

大きさが変わらない要素を宣言して高速化する

.widget {
  contain: layout style paint;
}

スケジューリング

HTTP Linkヘッダ

のHTTPヘッダ版
HTMLのパースを待たずにDL開始

Link<style.css>:rel=stylesheet

preloadヘッダ

WebフォントやCSS等

requestTimingIdleCallback

アイドル時間に実行させる優先度の低いタスクを渡す。

大量の要素を高速に表示する婆バーチャルレンダリング入門

久保田 @anatoo

バーチャルレンダリングとは
仕組みと実装

バーチャルレンダリングとは

speakerdeck.com

パフォーマンスのためのテクニック
ウェブページに大量の要素を高速に表示するためのテクニック

普段から使っている(react-infinite)https://github.com/seatgeek/react-infiniteとかのことだったので、
あんまメモってない。
iOSのUITableViewとかもそうだったはず。

こっからLT

WebWorker & Atomics

自分

WebWorker and Atomics from 青野健利

www.slideshare.net

組織にパフォーマンスを根付かせる