►
From YouTube: WebPerfWG Design call - August 8th 2019
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
Thought
you're
driving
the
triage
schedule
tequila,
but.
C
B
C
A
F
A
C
A
A
So
with
that,
out
of
the
way,
let's
talk
about
tea
pack,
we
started
document
sketching
out
a
rough
idea
of
what
the
agenda
may
look
like.
We
have
Monday
and
Tuesday
there
and
we
were
talking
about
the
division
between
those
into
which
parts
we
need
for
design
which
parts
for
working
on
issues
and
if
we're
working
on
issues
should
we
go
for
trash
related
discussions
or
you
know
more
hands-on
sessions
where
people
actually
get
work
done.
E
A
A
F
Like
to
maybe
discuss
a
little
bit
about
some
of
the
features
that
work
or
the
changes
to
the
research
timing,
spec
that
we're
thinking
about
for
visibility
into
cross-origin
iframes,
and
if
we
can
get
any
visibility
and
with
the
similar
kind
of
bubbles
feature
where
we
can
easily
notice
all
a
frames
activities
on
the
page
as
well.
Even.
F
B
We
talked
about
recording
and
any
ill
there's
some
outstanding
feedback,
so
I
think
we'll
have
to
reach
out
and
see
if
we
can
loop
in
some
of
the
folks
that
are
missing
from
this
group
to
resolve
those,
then
I'm
a
been
well
I
may
lean
on
you
to
get
some
feedback
from
from
Mozilla
on
those,
because
I
think
you
guys
have
some
good
feedback,
but
we
just
need
to
figure
out
how
to
I,
don't
angle
it
and
make
it
all
work.
Okay,.
G
A
B
Okay,
okay,
so
the
AI
is
just
to
recap:
the
a
eyes
are:
there's
a
doc.
That's
been
shared
on
public
web
mailing
list,
it's
also
in
the
minutes.
So
please
go
inside
and
add
yourself
to
the
list
of
attendees.
If
your
remote,
let
us
know
as
well
we're
trying
to
figure
out.
How
are
we
gonna
support
that
better,
hopefully-
and
please
add
any
topics
there
and
I-
think
we
are
landing
on
first
day
as
design
discussions
days
roughly
issued
triage,
but
those
are
malleable
based
on
who
we
need
in
the
room
for
what.
A
H
Shared,
let
me
know
if
you
guys
see
my
screen-
yep
perfect,
all
right,
so
a
Kirsch
for
those
of
you
who
don't
know
me:
I
work
at
Akamai,
owned
by
performance,
related
problems.
So
today,
I
wanted
to
talk
about
some
of
the
use
cases
around
CPU
reporting
that
I've
been
trying
to
document
and
sharing
it
publicly
with
developers.
H
Is
it
only
the
CPU?
That
is
that
that
will
make
the
device
slow,
an
old
phone
with
it
with
a
slow
C
new
processor
could
be
any
slow,
a
device
a
fast
device,
but
in
a
battery
saver
mode
could
also
make
that
fast
device
slow.
The
device
may
have.
You
know
faster
course,
bar
the
device
may
already
be
under
heavy
load.
So
all
of
these
things
and
they're,
potentially
others
that
will
make
the
device
slow
so
focusing
on
you
know
if
the
browser's
could
expose
see
if
you
CPU
related
information
back
to
the
developers.
H
H
We
could
think
about
removing
animations
from
the
page,
replacing
image,
Corral
zones
with
static
images
and
even
use
lower
compression
levels
when
uploading
the
data
and
then-
and
this
may
tie
into
the
upload
implode
compression
proposal
that
we've
been
talking
about
so
overall
think
about
delivering
amp,
like
pages
which,
which
have
a
very,
very
stripped
down
version
off
a
subset
of
HTML
command.
X,
even
you
know,
JavaScript
less
pages,
think
about
delivering
features
to
the
page
that
do
not
require
polyfills,
so
try
to
build
websites
with
already
natively
supported
features
that
most
browsers
already
support.
H
The
other
category
that
I
thought
of
was
running
some
sort
of
computation
on
the
cloud
whenever
possible.
So,
for
example,
I'm
server-side,
rendering
it
tries
to
figure
out
the
layout
of
an
AM
page
and
puts
all
the
layout
specific
information
in
the
amp
HTML
itself
and
only
then
deliver
to
the
client
and
that
helps
speed
up
the
rendering
time
and
as
well
as
some
other
metrics
that
help
improve
the
user
experience.
So
this
is
one
of
the
things
that
could
be
done
on
the
cloud
and
then
push
to
the
client.
H
Often
browser
tries
to
do
some
of
the
JavaScript
heavy
computations
back
on
the
cloud
and
then
send
some
sort
of
a
Java
JavaScript
heap
to
the
client,
and
then
it
processes
the
JavaScript
heap.
So
in
the
end
we
device
is
doing
less
computation
on
the
dawn
on
the
CPU
and
so
the
page
loads
faster
and
we're
not
a
few
academic
papers
that
talk
about
generating
JavaScript
heaps
in
the
cloud
and
of
course
they
have
some
limitations.
H
Actually
I
think
someone
came
up
with
someone
actually
mentioned.
The
document
that
web
fee
seems
to
seem
seems
to
take
a
lot
of
computers,
a
lot
of
decoding
time
on
slow
devices,
and
so,
if
we
could
identify
that
hey,
this
is
a
slow
device.
Maybe
let's
send
an
image
in
a
different
format
that
decodes
faster
on
the
device
and
I
think
you
have
your
proposal
around
resource
processing
time
that
tries
to
estimate
how
long
a
resource
to
process
on
the
device
be
JavaScript
or
images
or
anything
that
happens
for
the
resource.
H
So
we
don't
know,
we
don't
only
have
to
think
about
slow
devices
and
in
fact
we
go
specialized
for
faster
devices.
If
we
know
a
device
is
faster,
we
could
we
could
do
something
on
the
back
end
as
well,
and
and
try
to
conditionally
run
certain
JavaScript
tasks
when
we
know
that
the
device
is
fast
or
is
not
under
heavy
load.
We
can
selectively
choose
when
to
run
certain
tasks,
given
the
instantaneous
load
on
the
device,
but
this
would
also
require
some
sort
of
an
API
JavaScript
API.
H
H
So
the
you
know,
so
it's
open
for
discussion
about
what
that
API
may
want
exposed,
should
it
expose
fur
the
fur
coat
load
or
the
total
CPU
utilization
and
a
lot
of
it
may
depend
on
what
is
available
or
what
is
reported
by
the
operating
system.
That
point
some
use
cases
were
around
how
we
can
associate
the
CPU
information
with
lot
of
performance
related
metrics.
H
We
are
already
collecting
using
ROM
systems
right,
so
we
may
think
about
looking
at
page
load
time
or
certain
certain
aspects
of
JavaScript
performance
and
tie
that
back
into
how
slow
or
fast
we
can.
We
classify
a
device's
things
like
looking
at
how
much
traffic
of
a
particular
website
is
getting
from
slow
device
versus
fast
device
and
think
about.
H
Is
it
really
I
do
really
need
to
optimize
for
slow
devices
given
they're
getting
only
a
small
fraction
of
traffic
from
slower
devices,
and
this
may
be
opposites
for
another
website
which
is
getting
a
lot
of
traffic
from
slow
devices,
and
so
it
makes
probably
makes
more
sense
for
them
to
think
about
how
they
want
to
optimize
for
how
they
one
optimize
their
website.
For
majority
of
their
traffic,
which
is
coming
from
slow
devices,.
H
H
H
So
so
one
idea
that
came
up
was
what
is
fast
enough
right
and
app,
and
application
developers
may
want
to
think
about
what
type
of
devices
are
fast
enough
for
their
applications.
So
one
example
could
be
any
device
that
has
a
CPU
clock
rate
of
more
than
2
gigahertz.
Maybe
it's
fast
enough
for
that
one
application,
or
maybe
that
one
application
thinks
that
anything
that
has
more
than
1.5,
gigahertz
or
Darkrai
is
fast
enough
right.
So
developers
may
need
to
identify
their
independent
needs
for
their
applications
and
think
about
what?
What
is
the
performance?
H
H
So
the
slowness
of
the
device,
like
a
said,
may
also
depend
on
the
CPU,
the
CPU
utilization
in
the
past
few
seconds,
a
few
minutes
and
it
could
fluctuate
a
lot
because
a
lot
of
different
applications
run
on
the
device
and
different
pages
require
different
resources
on
the
CPU.
So,
depending
upon
the
user,
be
it
the
user
browsing
behavior
and/or.
The
other
applications
running
on
the
device
may
contribute
to
how
much
he
butyl
ization
is
a
browser.
Could
report
right,
so
this
number
would
fluctuate.
H
So
over
time,
like
I
said,
a
device
fast,
which
is
fast
today,
may
not
be
fast.
Tomorrow,
applications
are
evolving
and
their
requirements
for
speed
are
only
only
growing.
So
if
we,
if
we
classify
devices
based
on
any
of
these
any
of
these
categories,
these
classifications
will
need
to
be
updated
based
on
based
on
how
the
applications
are,
they
are
being
updated
and
how
and
how
the
how
the
mobile
market
is
moving
forward,
bringing
faster
and
faster
devices
as
the
users
are
moving
towards
faster
devices.
H
Exposing
all
right
like
I,
said
goals,
processors,
clock
rate
is
one,
maybe
maybe
maybe
some
sort
of
a
browser
decide
a
browser
bucketed
way
of
telling
the
the
developer
that
the
device
is
very
slow
or
slow
or
fast
right
or
some
sort
of
a
score.
That
lesson
developer
know
hey.
This
is
five
out
of
ten
or
seven
out
of
ten,
but
that
school
needs
to
be
changed,
because
we
also
don't
want
newer
devices
to
approach
ten.
H
So
so,
going
over
the
use
cases,
I
I
didn't
really
come
across
any
use
case
that
specifically
needed
any
of
these
properties
being
exposed.
You
know,
like
TP,
Corsa
processor
number
of
processor
clock
right.
There
were
any
use
case.
That's
that
that
required
one
of
these
things
specifically
so
one
of
the
other
things
like
I
said,
could
make
a
device
low,
is
the
battery
saver
mode
but
and
I
don't
think
the
browser's
expose
whether
the
battery
saver
mode
is
active
or
not.
H
A
H
H
I
I
That's
accurate
as
a
an
expectation
of
you
know
some
fuzz
thing,
and
so,
like
the
idea,
you
know
they're
mining
only
doing
crypto
binding
on
fast
machines.
Well,
first
off,
they
would
probably
just
run
the
stupid
thing,
but
secondly,
the
real
thing
you
would
do
is
you'd
benchmark
your
little
benchmarks.
You'd
run
it
say:
is
this
fast
enough
to
meet
your
criteria
and
then
you
know,
and
still
like
the
idea
that
an
iPhone
could
mask
itself
from
Discovery
about
what
the
underlying
CPU
is.
I
I
Is
you
know
the
browser's
have
sort
of
worked
hard
to
try
and
avoid
that
information,
because
they
can
reveal
things
about
like
one
of
their
sites,
sirs
logged
into
and
hey
I,
try
and
load
this
frame,
and
if
it
does,
a
ton
of
work,
but
user
has
logged
into
that
site,
and
so
I
just
watched
my
CPU
usage
and
see.
Oh
look
a
lot
of
CPU
usage
going
on
right
now
and
stuff
of
that
user
like
it
running
as
opposed
getting
a
404,
you
need
to
login,
oh
yeah.
I
This
info
is
already
in
the
user
rates
in
one
way
or
another,
but
its
applicability
and
the
ability
to
make
this
bizmates.
Not
it
is
it
ain't,
probably
right,
I
think
I
think
it.
You
know
a
lot
of
the
scenarios
come
down
to
hey,
we'll
give
the
user
fast
content
if
their
device
is
slow
and
I.
Think
there's
a
lot
of
examples
that
suggest
giving
the
user
fast
content
even
on
a
fast
device.
That's
a
good
idea.
I
H
Your
idea,
around
benchmarking
and
seeing
how
fast
something
runs,
I
think
that
benchmark
is
only
valid
for
that
one
instance
of
the
benchmarking,
because
maybe
the
device
wasn't
overload
at
that
time,
and
so
the
benchmarking
you
did
gives
you
good
numbers,
but
then
next
time
you
try
to
actually
load
load,
something
on
it,
which
is
going
to
be
used
by
the
real
user.
The
device
is
super
loaded
and
the
benchmark
you
collected
earlier
is
not
applicable
anymore.
What.
I
I
mean
to
say:
is
you
benchmark
on
the
user's
device
so
like
when
I
go
to
Netflix?
It
drops
like
two
Meg's
over
an
exhalation.
If
he
can
actually
see
how
fast
my
connection
is,
and
then
it
gives
me
a
different
user
experience
and
that's
the
I
mean
again
like
you're
right
that
hey
the
device
after
that
benchmark
process
runs,
could
suddenly
come
under
load,
but
that's
true
anything
right
user
through
device
is
fast
and
then
they
start
building
Chrome.
I
H
And
you
know
it's
just
not
related
to
browsers.
It
happened
in
so
many
areas,
even
with
CD
and
mapping.
You
know
we
look
at
historic
data
and
try
to
figure
out
performance
of
different
links
on
the
Internet
and
try
to
figure
out
where
to
send
this
line,
but
but
we
we
do
that
based
on
the
historic
era
right,
the
past
32nd
data
and
when
we
send
the
fine,
we
don't
know
how
fast
it's
gonna
run
at
that
point
right
so.
E
In
also
many
of
the
examples,
users
that
are
very
largely
affected
by
weather
Sutton,
how
do
addict
encoding
and
decoding
happen
in
the
device
right
or
like
what
kind
of
bras
is
being
used?
I
mean
our
for
mass
of
junk
is
so
different,
depending
on
which
browser
is
being
used
right
and
which
version
of
browsers
used
me.
Cpu
performance
may
not
be
almost
irrelevant
because
in
depending
on
the
browser,
maybe
something
runs.
You
know
10
200
times
faster
than
other
browsers,
sure.
A
E
I
Are
you
part
of
this
scenario
right
like
do
you
have
hardware
decode
on
your
GPU
for
a
particular
media
format
right
like
some
of
that
information
at
some
point
was
exposed
for
the
WebGL
API
is
and
they're
like?
Oh
that's,
too
much
data,
but
I
guess.
The
overall
point
is
like
the
the
notion
of
having
generic
general-purpose.
Give
me
one
number
to
get
the
performance
of
the
machine.
Usually
it's
inaccurate
for
the
workload
of
light.
I
Yes,
I'm
doing
hardware,
encoding
or
decoding
a
video
like
the
CPU
is
almost
irrelevant
as
long
as
I'm
getting
the
hardware
decoding
capability
and
similarly,
you
may
have
wildly
different
performance
characteristics
like
I
could
have
eight
tiny,
pretty
ARM,
cores
or
I
could
have
one
blazing
fast,
I
nine,
you
know,
and
you
know
just
the
number
of
cores
is
not
necessarily
gonna.
Give
you
the
thing
that
you're
interested
it
might.
You
know
help
you
do
number
of
workers
this
bought,
but.
D
Yeah
is
it
do
we?
Is
there
any
consensus
that
if,
if
just
some
idea
of
battery
saver
or
kind
of
clamped
clock
is
that
gonna
get
us
80%
of
the
way
there
with
this
stuff,
our
sip
exposing.
E
Power
saver
status
is
a
showstopper
that
is
just
not
okay
from
user
privacy
perspective
yeah.
There
is
a
study
research
showing
that
the
websites
are
using
that
to
track
the
user.
In
fact,
the
people
who
have
more
money
tend
to
always
keep
the
battery
full
and
don't
use
power
saver
so
like
this
is
just
like
showstopper
showstopper.
That
is
just
simply
on
okay,
okay,
dude.
Can
you
put.
I
Think
it
also
is
related
to
the
battery
status
API
of
like
what
is
the
level
of
the
battery,
and
there
was
a
lot
of
concern
about
revealing
not
to
websites,
because
somebody
had
hypothesized
that
uber
could
charge
you
more
if
your
battery
was
about
to
die
and
even
though
I
don't
think
that
was
the
thing
that
ever
happened.
It
is
now
in
the
lexicon
as
a
thing
that
happens
and
how
various
Hauser's
have
ripped
it
out.
Instead,
we're
never
going
to
do
that,
but
I
mean
the
other
question.
I
would
have.
I
Is
our
sites
using
these
sorts
of
signals
today,
and
so
the
one
that
immediately
comes
to
mind?
Is
the
data
saver
client
hidden
like?
Are
we
seeing
a
significant
number
of
sites
adopting
that
and
doing
something
useful
with
it,
because
I
feel
like
that
would
be
the
same
class
thing
like?
Are
we
seeing
data
saver
use
and
know?
Are
they
are
they
reacting
different
lady?
So.
H
It
would
maybe
maybe
a
little
different
of
an
indicator
than
device
under
heavy
load
why
the
user
is
with
the
data
say
when
the
user
is
interested
in
saving
the
data,
because
it's
it
has
a
limited
cap
on
on
the
monthly
data
plan
that
the
user
has.
But
it
does
tie
back
into
reducing
the
size
of
the
content.
We
ship
it
to
the
user,
but
mostly
because
you
ship
less
outfit
but
not
less
complex
right.
I
I
G
Google
and
chrome
partnership
side
of
things
in
the
last
year,
we've
seen
an
uptick
in
the
number
of
large
sites,
so
eBay
Facebook
tender
who
are
interested
in
differential
loading
and
are
using
the
available
signals
in
the
platform.
So
effective
connections
hype
Emery
any
memory
signals
we've
got
available
battery
status,
even
in
order
to
send
down
lighter
experiences
or
turnoff
the
serving
of
heavier
features
to
devices
they
don't
think
can
handle
them
lacking
a
clear
platform
signal
for
CPU.
Some
people
are
starting
to
explore
client-side
benchmarking
to
get
some
some
idea
of
CPU
over
time.
G
Some
people
are
doing
a
little
bit
of
sampling
over
the
lifetime
of
the
user.
To
get
an
understanding
of
that.
Other
people
are
doing
interesting
things
like
mapping
so
using
the
UA
and
other
signals
available.
Can
they
build
up
a
database
of
what
we
think
your
device
is
and
then
cross-reference
that
with
deeper
information
about
you,
know
your
CPU
and
how
things
are
decoding,
etc.
So
there
there
is
an
increase
in
interest
in
this
from
real
sites.
As
far
as
I'm
saying.
D
E
D
E
Even
pager
but
like
let's
say
that
you're
showing
some
a
chat
pane
on
the
side
right
and
maybe
each
time
campaign
updated,
it
gets
updated.
Maybe
you're
you
know
measure
whether
you're
missing
a
frame
is
based
on
request,
animation
frame
if
you're
missing
a
frame
every
single
time.
Maybe
you
dating
too
much
may
be
shown
I
mean
there
many
things
you
can
do
even
today
without
any
new
API
to
measure
how
well
your
website
is
performing
on
a
device,
as
the
websites
performing
sure
they're.
A
They
are
more
complex
to
developed
an
active
measurement
and
therefore
people
tend
to
do
active
measurement
more.
If
this
is
something
they're
interested
in
and
it's
very
hard
to
like
that
doesn't
address
like
relying
on
passive
measurements,
doesn't
address
most
of
the
use
cases
I
think
because
in
some
cases
it's
too
late
well
by
the
time
you're
missing
frames,
you're
already
too
late.
You
already
delivered
the
bad
experience
to
that
user.
A
It
also
doesn't
you
to
correlate
performance
based
on
different
device
speeds
but
yeah.
At
the
same
time,
there
are
real
fingerprinting
concerns
and
real
concerns
about
which,
like
how
many
bits
and
which
bits
we
can
expose
as
part
of
that
and
I,
think
that
the
use
case
is
viable
and
real
and
not
something
that
people
can
just
do
with
passive
observations
today.
At
the
same
time,
we
need
to
yeah
to
estimate
the
trade-off
between
this
and
user
privacy
and
see
what's
this
yeah,
how
many
bits
we
can
expose.
A
I
know
that
in
in
the
past,
we
talked
about
something
like
Facebook's
device
year
or
device
class
where
they
classify
devices
based
on
some
perception
of
in
this
year.
That
was
the
average
device
or
the
80
percent
percentile
device,
or
something
along
those
lines
and
I'm
wondering
if
this
would
be
something
that
would
satisfy
the
use
cases,
because
it's
like
it
will
explode
the
relatively
low
number
of
bits,
even
though
it
will
expose
them.
A
H
H
They
would
look
at
when
that
phone
was
released
and
they
was
2010
and
they
would
look
at
the
average
CPU
never
released
for
phones
in
2010
and
I
would
say
any
device
that
belongs
to
this.
This
CPU
information
that
is
from
2010,
even
though
the
device
was
launched
in
2017,
they
were
still
classify
it
as
2010,
because
you.
H
Cp
information
yeah
so.
H
So
I
I
mean
I
I
did
try
to
look
at
some
data
that
I
collected
from
GSM
Arena
around.
You
know
how
fast
and
slow
the
devices
are
based
on
number,
of
course,
and
processor
speed,
but
I
didn't
really
have
a
strong
inclination
towards
using
that
for
making
a
dying
into
the
Facebook
career
of
class.
Yet
I'm
just
wondering
what
what
what
what's
the
motivation
here?
Why
do
you
think
that
would
that
could
work?
H
Right,
exposing
the
ear
may
not
be
interesting,
because
every
every
developer
would
need
to
know
what
that
year
actually
means,
and
they
may
need
to
work
with.
The
data
said
that
Facebook
has,
or
you
know,
think
about
how
what
what
that
2010
means
for
their
application
versus
what
2017
means
for
their
application,
as
opposed
working
directly
on
the
CPU
numbers.
B
Refers
to
reframe,
maybe
yields
question
may
be
the
year
is
not
the
right
thing
to
fix.
I,
don't
fixate
on
I
think
the
question
is
more
around
on
the
spectrum
of
how
much
information
you
expose
like
there
is
a
static
single
bit
that
you
could
expose,
or
maybe
some
very
limited
number
of
categories
it
could
be
a
year.
It
could
be
fast,
average
slow
one
to
ten
ABC
I,
don't
know
what
it
is.
It's
like
some
very
limited
set
of
signals
and
then
moving
off
that
line.
You
know
I
thought
the
other
extreme.
B
B
D
Yeah
the
use
cases
just
to
clarify
we're.
We
had
thought
about
that
based
on
Jill's
paper,
but
we
have
not
actually
implemented
any
of
the
cpu
pressure
metrics
just
to
clarify
yeah
wait.
We
were
mostly
interested
in
doing
it
as
a
way
to
threat
not
from
a
website
operator
perspective,
but
more
from
a
browser
perspective
where
we
would
like
to
collect
performance
data,
and
if
we
knew
from
the
performance
data
that
the
CPU
was
discounted,
then
we
would
bucket
those
performance
results
in
a
separate
container.
D
So
that's
that
was
our
main
use
case,
although
we're
very,
of
course,
concerned
about
the
privacy
implications,
so
I
was
I,
wanted
to
kind
of
explore
and
see
if
there
was
a
way
to
do
this
and
it
keeps
some
semblance
of
privacy
and
it
does
not
seem
like
we
have
reached
a
conclusion
on
that,
and
that's
my
gut.
If
you
want
us.
Okay,.
A
D
B
So
of
a
path
forward
here,
first
of
all,
thank
you
for
doing
called
all
the
like
work
here.
There's
lots
of
good
research
here,
I'd
love
to
capture
some
of
the,
even
if
we
can't
provide
an
API
I
feel
like
there's,
not
portunity
here,
to
provide
some
guidance
for
like
there.
We
know
that
there
are
classes
of
use
cases
here
and
we
can
make
some
recommendations
for
how
to
like
to
or
do
not
approach
this
sort
of
problem.
So,
for
example,
I'm
thinking
of
the
one
use
case,
I
think
I
heard
from
I,
don't
remember.
B
The
the
person's
name
from
Microsoft
working
on
Excel
was
like
I
want
to
run
some
speculative
calculations,
and
but
I
don't
want
to
run
them
if
they're
gonna
jank
my
next
ten
frames,
but
I
still
want
to
run
them
because
there's
value
to
the
user
so
now
I
have
a
chicken
and
the
egg
problem.
It's
like
how
do
you
reason
about
that
space?
B
In
theory,
that
would
be
the
long
task.
Api
like
in
theory
like
one
recommendation
here
could
be
like
look.
We
can't
predict
the
future,
but
you
could
have
observed
long
tasks
for
a
while
and
observes
that
you've
been
dropping
frames
and
because
of
that,
you
should
do
less
speculative
optimization,
like
or
speculative
calculation,
not
not
simulation
like.
That
seems
like
a
practical
I.
Don't
know
people
use
that
in
a
wild,
but
it
could
be
a
recommendation.
Yeah.
A
A
H
Also
wondering
if
you
know
the
developer
needs
to
have
enough
number
of
hints
from
the
device
that
it
has
been
slow
and
seconds
ago.
It
has
been
slow
20
seconds
ago.
It
has
been
slow
30
seconds
ago
and
so
to
see
that
the
device
has
been
slow
enough
number
of
times
would
make
make
the
developer
believe
a
little
bit
more
that
yes,
it's
it's
in
general,
it's
slow
divisive.
Let's
do
something
now,
as
opposed
to
just
looking
at
one
signal
of
device
being
slow
and
acting
upon
it.
A
But
at
the
same
time,
Erik
commented
earlier
that
exposing
the
general
CPU
state
of
the
system
has
a
lot
of
privacy
implications
that
go
beyond
fingerprinting.
So,
if
I
have
you
know
and
can't
the
classic
example
that
I
also
came
to
my
mind,
is
yeah
I'm,
building
a
browser
on
my
machine
right
now,
and
that
is
you
know,
potentially
valuable
information.
I
am
sure
there
are
other,
so
yeah
you're
using
hangouts
and
that's
taking
hundred
percent
of
you.
A
A
B
B
Is
that
we
may
have
enough
low
level
building
blocks
to
assemble
a
reasonable
model
to
address
at
least
some
subset
of
these
keys
here
there
is
definitely
some
signals
that
are
missing
like
the
roam
analytics
or
sort
of
thing,
although
even
there
maybe
you
can
create
some
composite
metrics
to
report
doc
and
it
may
be
like
I
think.
Actually
it
is
the
case
that
there's
a
number
of
use
case
here
that
we
just
we
cannot
address,
because
privacy
and
fingerprinting
and
that's
just
not
aligned
over
and
out
we're
gonna
cross.
A
H
So
so
what
also
thought
about
the
fact
that
the
CPU
load
on
the
device
doesn't
have
to
be
origin,
specific
right
and
if
the
browsers
could
look
at
how
different
pages
from
different
origins
have
been
loading
in
the
past
asked
whatever
number
of
seconds
they
could
just
come
up
with
a
score
and
say
hey.
This
is
how
slow
or
fast
the
device
is
in
the
past.
E
If
the
users
taking
a
train
and
moving
from
station
to
station
while
loading
page,
though
it
might
be
slow
right
and
then
user
stops,
the
transition
gets
other
traces.
You
get.
The
fast
Wi-Fi
I
mean
totally
breaks
down.
In
that
scenario
like
you're
driving,
you
know,
if
you're
in
a
car
previously
and
then
stop
right,
I.
B
A
B
Thank
you
crush
once
again
and
and
just
to
reiterate,
I'd
love
to
see
some
dock
or
some
more
thinking
going
on,
and
maybe
I
can
help
chip
in
there
as
well
for
how
we
can
make
some
recommendations
in
the
space,
because
I
do
feel
like
there's.
Some
really
valid
use
cases
here
that
people
are
trying
to
address
today
and
it'd
be
really
nice
if
we
had
some
recommended
path
for
them
to
like,
if
you're,
building,
Excel
and
you're
doing
speculative
calculation,
here's
how
we
recommend
you
do
it
like
here
are
the
building
blocks.