| 06:58 | <sideshowbarker> | So I’m writing the intro of an MDN page for the Paint Timing API and want the intro to put the Paint Timing API in context relative to the Largest Contentful Paint API. |
| 07:00 | <sideshowbarker> | Would it be accurate for me to make it basically say the Largest Contentful Paint API aims to provide timing information that’s more useful in practice, to the point that it obviates need for the Paint Timing API. |
| 07:02 | <sideshowbarker> | In other words, implying (if not explicitly saying) that if you have access to the Largest Contentful Paint timing info, that’s better info and you wouldn’t also have use for knowing when first contentful paint occurred. |
| 07:05 | sideshowbarker | looks around for Noam Rosenthal |
| 07:11 | <sideshowbarker> | I have a vague recollection that during discussion with the WebKit team, they may have said that in their implementation, one of these paint-timing metrics wasn’t something that’s very useful in practice for developers to know. Or else, not something that their implementation doesn’t even make measurable such that it could be exposed to web content. |
| 07:36 | <Domenic> | Chrome prioritizes LCP over FCP in Core Web Vitals. This was done based on some analysis and data showing that LCP captured user experience better. Perhaps that is what you're thinking of? |
| 07:39 | <Domenic> | Some discussion at the intro to https://web.dev/lcp/, but not much... maybe there's a better source. |
| 08:19 | <Noam Rosenthal> | I think FCP are LCP are both useful, in different ways and depending on the content |
| 08:19 | <Noam Rosenthal> | they are two important points in the loading experience. LCP is more important for CWV but both can give the developers a good hint about how your loading went |
| 08:20 | <Noam Rosenthal> | e.g. if you have a small "Loading" icon and then all the real content loads, FCP will give you the time of the loading icon and LCP will give you the time of the entire content |
| 08:21 | <Noam Rosenthal> | for pages like wikipedia, FCP is very important - it's the time where the wikipedia content loads. Afterwards maybe some big image would load and be the LCP, but both timings are meaningful. So like I said it's content-dependent |
| 08:21 | <Noam Rosenthal> | CWV is an attempt to crystalize all the different metrics to 3 magic numbers, but many times you need more metrics than that to get the whole story and optimize |
| 08:22 | <Noam Rosenthal> | sideshowbarker: ^^ |
| 08:25 | <Noam Rosenthal> | sideshowbarker: the webkit team discussion was about first-paint. They didn't want to include it because it was not useful given that webkit buffers painting until it's contentful |
| 09:41 | <hsivonen> | hsivonen: https://html.spec.whatwg.org/multipage/iframe-embed-object.html#the-iframe-element:process-the-iframe-attributes-3 object doesn't have a similar initialInsertion flag. Not sure yet, if this is a spec oversight or a genuine platform difference between object and iframe. |
| 09:57 | <sideshowbarker> | Noam Rosenthal: If you have time to look over https://github.com/mdn/content/pull/20346 and call out any problems you see — or any improvements that could be made — that’d be much welcome. |
| 09:59 | <sideshowbarker> | Some discussion at the intro to https://web.dev/lcp/, but not much... maybe there's a better source. |
| 10:01 | <sideshowbarker> | Some discussion at the intro to https://web.dev/lcp/, but not much... maybe there's a better source. |
| 10:21 | <zcorpan> | hsivonen: I don't know either re object vs iframe |
| 10:22 | <hsivonen> | hsivonen: I don't know either re |
| 11:10 | <Domenic> | object spec is a giant mostly-unmaintained mess... if you can make object more like iframe, that would be a great end state |
| 11:13 | <Noam Rosenthal> | Noam Rosenthal: If you have time to look over https://github.com/mdn/content/pull/20346 and call out any problems you see — or any improvements that could be made — that’d be much welcome. |
| 11:14 | <Noam Rosenthal> | sideshowbarker: I'll also ping other people in my team to take a look |
| 11:51 | <sideshowbarker> | Noam Rosenthal: I see that PR got merged before your comments came in. We tend to merge PRs relatively quickly — and for MDN I think that’s a good thing in general. But for your changes I’d be happy to open a PR myself. Or leave it up to you — whichever you prefer. But regardless, it’d still be great to have review from others on your team too for the https://github.com/mdn/content/pull/20346 changes. And rather than needing to view the diff, anybody can review the current state of the content, with the changes merged, at:
…or else, within the next 48 hours at most, the production site will have the updated content at: |
| 13:36 | <Noam Rosenthal> | sideshowbarker: no worries, I'll post a correction PR. The PR has links to those previews, so I think the team will manage (I already passed it along). Thanks! |
| 13:44 | <Noam Rosenthal> | sideshowbarker: https://github.com/mdn/content/pull/20351 and https://github.com/mdn/content/pull/20350 |