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
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
<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]
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
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?
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]
<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].
[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?
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/you can tell/you can't tell/ Succeeded: s/than 15ms/than 50ms/ Succeeded: s/extremely/not extremely/ Succeeded: s/task ads/task besides ads/ Succeeded: s/double-click things isn't too back/double-key things isn't too bad/ Succeeded: s/whether to provide detail/perhaps provide less detail/ Succeeded: s/Elliot/esprehn/ Succeeded: s/- Time to Interact/ - Visually Complete - Time to Interact/ Succeeded: s/Visually/Visual/ Succeeded: s/will be slow/will be slight different/ Succeeded: s/soos/soon/ Succeeded: s/kill it/add it/ Succeeded: s/deviceve/derived/ Succeeded: s/into/from/ Found Scribe: xiaoqian Inferring ScribeNick: xiaoqian Present: igrigorik toddreisteck yoav nolanlawson rniwa keiji shubhie xiaoqian Nathan_Schloss smaug Paul_Irish RickB slightlyoff Ojan WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 Guessing minutes URL: http://www.w3.org/2016/09/23-webperf-minutes.html People with action items: yoav WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]