TPAC Web Performance WG meeting -- 23 Sep 2016

Long Task API proposal

shubhie: entryType is going to be “longtask”

yoav: if I have a iframe that taking a long task, I will just see the iframe loading?

shubhie: right

smaug: Is there still possible security issue?

shubhie: we got a detail privacy discussion section

https://github.com/spanicker/longtasks#privacy--security

rniwa: if you are the only one top-level, you don't have guarantee the long task have the iframe

keiji: you can't tell if there is other tab opened

smaug: you don't know other window or tab that running the process

yoav: with high probability

shubhie: we have some informal discussion about security

igrigorik: we have two tabs opened, that share the same process

keiji: if you have multiple tabs, you need the baseline, and see if it's moving or not

nolanlawson: you can only succeed the attack if the task takes longer than 50ms

yoav: the end goal of this reporting API is that there would be 0 long tasks

igrigorik: if there's an iframe, with a unload, which include only JS, is it still the same attack?
... but the concern is a fair point, worthy further discussing with the sec team

smaug: will it be useful to start from same-origin?

toddreifsteck: publishers want this

shubhie: [demo on prototypes]

yoav: if a long task never ends, when will it get reported?

shubhie: on mobile it's uncertain
... in v2, if there's a single script, it's easy to point to it
... the way we came up with this is from the RAIL guideline

https://developers.google.com/web/tools/chrome-devtools/profile/evaluate-performance/rail?hl=en#animation-render-frames-every-16ms

shubhie: 50ms is the default, but the users can set it

igrigorik: 50ms is just a user presumption

[demo of a partial implementation]

https://spanicker.github.io/longtasks/demo.html -> Chrome Canary 55.0

igrigorik: wiki is top level page, if there's a script running, so I will only see the name of the page?

shubhie: right

nolanlawson: Does it mean it's not extremely useful for same-origin?

shubhie: true for V1

toddreifsteck: should we put URL is a string format?

igrigorik: most developers don't have the concept of top-level things

n8s: good to have information for script and layout

toddreifsteck: does developers really need browsers to show tasks?

yoav: what can developers do if there are long tasks? when there are many long sub-task?

nolanlawson: with micro tasks you can deceive this interaction

rniwa: show attribution is uncomfortable in the cross origin cases

igrigorik: true but no way to avoid it

rniwa: many media sites may have long task besides ads

toddreifsteck: long task provides hints which is useful for the perf team of the publishers

keiji: is v1 just for first party?

igrigorik: for 1st party, there is less concern for privacy and sec

slightlyoff: inters-observer, maybe not colour the links, but we can do better by colouring between :visited
... we only colour the link you throw to chain
... that's data we want to get, so that's the next step
... if the impact isn't too large, it will simplify the process

toddreifsteck: the timing attack is an issue for visited history

n8s: double-key things isn't too bad

yoav: it will help to increase the functionality for visited links, for designers

<n8s> *double keying

shubhie: there are considerations what can the we see in terms of URLs and attributes? when you are in the same iframe tree?
... cross-origin, different tabs, vendors

toddreifsteck: v1.5, I think should be breaking down the sub-tasks

rniwa: the most important to have the information, whether it's layout, or...

toddreifsteck: does it really provide HR time stamp to ads?

shubhie: for script, we provide inform about run, next one is layout

igrigorik: so you got a long task, that has an array of TaskAttributionsTiming...

toddreifsteck: we would want to have sub- in this list, but we will run into privacy and sec

shubhie: only show those exceed 50ms

toddreifsteck: first question, is it the script or the style?

rniwa: information about what the script is doing matters

yoav: can you trigger style recount by script?

toddreifsteck: if that's a script that change the class, what will be the type?

shubhie: it will show up as script in the current design

toddreifsteck: will be useful to have hint about layout re-count

rniwa: creating these arrays is expensive

smaug: if every listeners need to call these benchmarks, that's going to cost

shubhie: The clock in Chrome is machine dependent

n8s: we sometimes do expensive perf measure, if there's value inside

rniwa: it make sense to have simple inform whether there will be expensive layout

toddreifsteck: chrome, same-origin, behind the flag

shubhie: waiting for feedback from other vendors
... attributions, good to show string content URL, should we have more information other than just showing the type?

toddreifsteck: TaskAttrTiming is flexible...

Paul_Irish: perhaps provide less detail for startTime and duration

Passive Event Listeners

<paul_irish> http://rbyers.github.io/scroll-latency.html

RickB: [demo for scroll jank]

<paul_irish> http://rbyers.github.io/scroll-latency.html

https://github.com/WICG/interventions

RickB: we need an API for developers to indicate that they will never call preventDefault

-> https://github.com/WICG/EventListenerOptions/blob/gh-pages/explainer.md

smaug: are you going to ship interventions in a separated spec?

RickB: Yep, it's in the WICG now

rniwa & smaug: Like the idea of interventions, but not comfortable to "ship" it in WICG

slightlyoff: Open discussion in WICG aims to get consensus

RickB: https://github.com/WICG/interventions/issues/18 -> passive touch listeners discussion
... webkit has passive event listener
... our priority list is touch, wheel@, keyboard

toddreifsteck: keyboard performance is a problem worthy looking into for us

Paul_Irish: there should be scroll latency

RickB: touch-to-start-scroll is our key metric

n8s: measurement cross browsers doesn't make much sense

esprehn: Is it possible to have timeline for user interactions?

rickB: make sense to have someone start from what to measure
... is performance timeline polyfill-able?

[no]

Progressive Web Metrics

PI: First Content to Paint - First Meaningful Paint - Visual Complete - Time to Interact

shubhie: https://github.com/tdresser/time-to-first-paint -> explainer for PerformanceFirstPaintTiming & PerformanceFirstContentfulPaintTiming
... the definition is the first non-blank for the browser
... more user facing than developer facing
... non-white might be slightly less than non-blank

toddreifsteck: shouldn't it be the first-non-change for background?

rniwa: right, user style sheet

yoav: whenever user see something happen?

PI: That's different, browser might change to white when it gets HTML

ojan: we don't want to define it by color

PI: first paint for something user can recognise

rniwa: using colour is weird, what if your site is complete blue

toddreifsteck: content for paint, in the pipeline, is it possible to slow down?

rniwa: just painting once will slow down everything

toddreifsteck: I suspect first paint will be slight different among different engines

rniwa: first contentful paint, if you have blue background with background text
... whenever you paint something different from the box model

n8s: if you already have good FP, if you want to improve FCP
... then definition of first-non-bg doesn't make sense

Ojan: the first thing that user would consider as content... may not the colour change
... we should consider bg-image as image
... your definition for FP might be better than non-white

toddreifsteck: Any data?

shubhie: not for this definition, coming soon

https://github.com/tdresser/time-to-first-paint#examples -> early examples

toddreifsteck: what about the processing model for paint?

rniwa: how does houdini paint?

ojan: every time you hook into the element?

ian: the closest thing is HTML paint
... an update in the rendering

toddreifsteck: do you want before or after layout?

ojan: there's a lot of time after layout

PI: define it as the latest timestamp you can commit to or after layout

rniwa: add step 13 as a checkpoint

esprehn: the timing recorded when the page is visible, but it may not come due to 16ms...

ojan: the time you include is the time after you painting and capable to run the next

toddreifsteck: one of our major concern is the black magic time

ojan: you don't compose a iframe...

rniwa: just measuring the main thread, if it's busy

ojan: the browser will try to run a if the main thread is busy

rniwa: we may not send it in time to the window

esprehn: true, there's a glass time, even all the window server are visible

ojan: the question how close we can get to perfect

toddreifsteck: we don't have a good way to report that number

esprehn: you can measure between the CA and the paint

igrigorik: we did some test, many pages didn't reach the stage to paint
... in nav l2, we killed performance entry after
... we could create an Performance paint timing interface
... still be a separated event

rniwa: we may not be able to add it immediately

keiji: is it really about paint?

toddreifsteck: user timeline??

shubhie: try not to make it paint specific
... something similar to paint timing, with different entry names

Time-to-Interactive

https://docs.google.com/presentation/d/1AnZOscwm3kMPRkPfjS4V2VUzuNCFWh6cpK72eKCpviU/edit#slide=id.p -> slides for PW Metrics

paul_irish: TTI is a time stamp when a page is loaded and ready for the user to interactive
... when we have a page load, look for a window without tasks longer than 50ms

igrigorik: why 10s?

paul_irish: we found some data from gmail
... the first user interaction is near 3s

igrigorik: interaction is safe when you have no long tasks?

paul_irish: we ran this definition on the top 9000 sites
... it feels good
... you can have busy main thread, and still have long task

rniwa: have anybody tried to interact before 10s?

ojan: the user experience can be terrible

igrigorik: if we have long task input event...

paul_irish: queuing time

slightlyoff: in the case you load the page, you may try to interact; it gives us a way to estimate the content load

yoav: it's possible that the page is interactive before TTI

esprehn: no one of these pieces is enough, unless they come together

rniwa: how does TTI if the user decide to interact in the other way?

paul_irish: it gets a push-back

ojan: there might be sites that don't need this metric, but the majority of sites meet the best practice

n8s: is it harder to measure by long task?

igrigorik: what will be the first class API for this mission?

yoav: there is not yet a golden standard in the industry

nolanlawson: this can be derived from long task

rick: how about starting from a open source lib based on long task and collect data

toddreifsteck: is there value or possibility to look for a number to estimate TTI?

slightlyoff: when people spend a long time on a file or a page, is it reasonable to load a script during which?

Hero Element Timing

https://docs.google.com/document/d/1yRYfYR1DnHtgwC4HRR04ipVVhT1h5gkI6yPmKCgJkyQ/edit -> Hero Timing proposal

shubhie: we want a time frame when the page is meaningfully rendered
... you can have a attribute on any element to annotate the hero element

rniwa: end time is more useful than start loading for large images

esprehn: image things should be treated differently
... for v1, don't provide information for CORS images

shubhie: should we limit the number of the element people annotate? - not doing it at the moment

rniwa: suggest name it element timing API

<rniwa> or Element Paint Timing API

https://github.com/w3c/user-timing/issues/17 -> parse, tokenize, render discussion

n8s: insert into DOM, when the thing come from the server and hit the document

yoav: so FMP is when all the hero elements are painted in the viewport?

[yes]

Dependency Trees

<scribe> ACTION: yoav to write a proposal on Dependency Trees [recorded in http://www.w3.org/2016/09/23-webperf-minutes.html#action01]

<trackbot> Created ACTION-174 - Write a proposal on dependency trees [on Yoav Weiss - due 2016-09-30].

Chrome Reflector

[free discussion]

Q1: How many data are we going to expose?

Q2: Security and Privacy Review When is a good time to start the review? Third party ( web apps & analysis team)? Who is reading the data?

- DRAFT -

TPAC Web Performance WG meeting

23 Sep 2016

Attendees

Contents