On Wed, Feb 26, 2020 at 11:33 PM Ryosuke Niwa <rn...@webkit.org> wrote:
> > On Wed, Feb 26, 2020 at 10:54 AM Noam Rosenthal <n...@webkit.org> wrote: > >> (resending from correct address) >> On Wed, Feb 26, 2020 at 8:08 PM Maciej Stachowiak <m...@apple.com> wrote: >> >>> >>> Some quick comments: >>> >> >>> the definition of First Contentful Paint here in the spec: < >>> https://www.w3.org/TR/paint-timing/#sec-terminology> does not match the >>> definition stated at <https://web.dev/first-contentful-paint/>. The >>> Chrome definition on web.dev specifies that iframe content is not >>> included, the spec does not have this limitation. Would an implementation >>> that matches the spec match Chrome? >>> >> The draft version of the spec specifies that iframe content is not >> included in FCP: >> https://w3c.github.io/paint-timing/#sec-reporting-paint-timing, and has >> a few more comprehensive details about this. I think it's a good place to >> start. >> >> I am also not sure this matches the layout milestones that already exist >>> in non-Blink browser engines. Has this spec been implemented in Gecko, for >>> example, to verity that it’s not exposing a concept that only exists in >>> Blink? >>> >> No, this has not been implemented in Gecko, I'm tracking the bug on this: >> https://bugzilla.mozilla.org/show_bug.cgi?id=1518999, there was some >> movement recently. >> >> I suggest to start from "first-paint", and to try to match chrome as much >> as possible in how FCP is implemented, in the cases where the spec doesn't >> give enough detail, if such places exist. >> > > I don't think we should do that. For starters, Chrome's painting strategy > while loading a web page is very different from that of Safari / WebKit. We > would freeze the painting of the previous page at the moment a new > navigation is committed, and we wouldn't update the painting until the > destination page has a meaningful content in it. This is a very much > different from Chrome's model where the moment a new navigation is > committed, Chrome will show a blank page then start incrementally painting > the page throughout the navigation. > > Second off, the point of specification is to allow multiple independent > implementations. If we had to reverse-engineer what Chrome is doing and > implement that, it defeats the point of having any standard at all. > With my WebPerfWG hat on, I agree. Would be good to find a model that works well for different implementations (even if not comparable between different implementations), while providing points in time for developers that can: a) provide a user meaningful visual metric and b) enable spotting regressions. Would WebKit folks be interested in helping exploration on that front? > > I also suggest to start with "first-paint" as it's perhaps a bit less >> "internal" than FCP, and can provide a performance-regression metric with a >> lesser degree of risk regarding exposing internals / privacy. >> > > I don't think we don't should that because we don't have an equivalent of > first-paint. > FWIW, I don't think it's a huge problem if WebKit will report FP and FCP as the same timestamp, as they are indeed the same point in time. > - R. Niwa > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
