3rd party IFrame assets being throttled / lazy-loaded

[Tommy Williams]

I have so many questions on this new feature, as I am sure it is broken (after we implemented proper benchmarking on our app across all browsers).

Document of intent for feature: 

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/czmmZUd4Vww/1-H6j-zdAwAJ

Our setup:

My company's video player is an embed script that creates an iframe and inserts a video element into it. It is our custom video player, has a lot of code behind it for ad management, etc.

Issue [bug?] discovered:

I saw this intent to 'lazy load 3rd party images & iframe data' in upcoming chrome release notes, and got scared. We did notice an extreme slow-down in our video player on all of our customer pages (in the range of 90% slower than Chrome 65) with a tens of thousands of instances to verify it is an issue). I confirmed that these pages aren't using our script to load the iframe below the fold, they are nearly all above the fold.

Breakdown of numbers to prove:

chrome	67	loadTime	15.11
chrome	66	loadTime	7.57
chrome	65	loadTime	1.51

I did some testing in Chrome 68 & 69 on my own. Our users aren't using beta or canary channels of Chrome, not enough data to support any improvement there, but my own testing showed that the loadTime numbers are a twee bit better in each new version (68 & 69).

Our approach:

I have been pulling out pieces of our code a little at a time, which is difficult to do since things are quite tightly coupled until our major refactor (that we pray happens one day). 

My Question to you:

Can you confirm there is a bug in the implementation of this only throttling iframes below the fold? It is apparent to us. A guess I have is because we load our iframe from a script, that may be flagged as 'below the fold' even though it isn't, since it is dynamically created and not on the page by default. 

Do you have any suggestions that I can try to fix this issue? Any Iframe policies that I am overlooking, or anything that we can do to trick the browser to tell our customer's website that our iframe is not a 3rd party (which I'm not super confident will fix this either, as we have seen slow pages on our own domains)?

Any guidance would be extremely helpful.

Thanks in advance,

Tommy Williams

[Tommy Williams]

"Deferred iframes": 

Referring to the "Blink LazyFrames" design doc I found in your chormium groups:

https://docs.google.com/document/d/1ITh7UqhmfirprVtjEtpfhga5Qyfoh78UkRmW8r3CntM/edit#heading=h.c7mc4hh4xdhq

This lists 4 points in which an iframe will be deferred. I'm using the option to display: none the iframe until all assets are loaded, and showing the iframe when ready to go, and our player was that was taking ~14s to boot in chrome 67 stable is loading on our devcdn via charles proxy in around ~4s!

On Mon, Jul 9, 2018 at 4:02 PM Scott Little <scli...@chromium.org> wrote:

(re-adding chromium-discuss properly this time, oops)

On Mon, Jul 9, 2018 at 12:58 PM Scott Little <scli...@chromium.org> wrote:

(re-adding chromium-discuss as CC since the original post has now appeared on the discussion board)

I'm not sure what caused the slowdown you saw, or why you saw an improvement by hiding the frame while it loads assets.

On Mon, Jul 9, 2018 at 11:43 AM Tommy Williams <webde...@gmail.com> wrote:

I do see #enable-lazy-frame-loading in canary and not 67... So, I wonder what the 'defer iframe assets' is attributed to, since we have proven that it is now sped up close to previously recorded speeds by hiding the iframe until assets are loaded, then showing the frame

#enable-lazy-frame-loading is the flag in chrome://flags that allows users to try out the frame-deferral part of lazy load in its current state, such as for debugging. By default, the feature is disabled right now, see code.

I'm not sure what you're referring to by "defer iframe assets".

 

On Mon, Jul 9, 2018 at 1:58 PM Tommy Williams <twil...@playwire.com> wrote:

Any ideas on what it was?

The part that shown light on it for me was (from https://docs.google.com/document/d/1ITh7UqhmfirprVtjEtpfhga5Qyfoh78UkRmW8r3CntM/ ):

An iframe will be deferred if it satisfies all of the following:

• It's a third-party iframe (i.e. a different origin than the embedding page),

• Larger than 4x4 in dimensions,

• Not marked as "display:none" nor "visibility:hidden",

• Not positioned off-screen using negative x or y coordinates

Which seems a little backwards to me. I am now hiding our iframe while it loads assets (at normal/faster/pre-67 speed). I would think anything visible would be loaded faster.

Understand, my terminology may be mixed up with 'lazy load iframes', that is just the thing that popped out to me in the generic change logs.

On Mon, Jul 9, 2018 at 1:50 PM, Scott Little <scli...@chromium.org> wrote:

FYI, LazyLoad is *not* enabled by default in Chrome 67 or any version of Chrome right now. See the code: https://cs.chromium.org/chromium/src/content/public/common/content_features.cc?q=LazyFrameLoading&sq=package:chromium

I'm glad that you fixed the problem, but LazyLoad wasn't part of the equation here :)

On Sat, Jul 7, 2018 at 5:35 AM Tommy Williams <webde...@gmail.com> wrote:

Those are in milliseconds. After writing this email and reading the documentation further (https://docs.google.com/document/d/1ITh7UqhmfirprVtjEtpfhga5Qyfoh78UkRmW8r3CntM/edit#heading=h.c7mc4hh4xdhq) I was able to find the issue! The feature is definitely enabled (set to default in chrome 67), it something we have been trying to tackle since first word of it. 

An iframe will be deferred if it satisfies all of the following:

I was able to fix our issue by understanding the 4 rules. I do appreciate the hasty response. I would ask change logs to be a bit more robust, as I am a Chrome (and Google) fanataic, I hate hearing 'Chrome is the new IE' getting thrown around. 

Live example from one of our publishers: 

https://www.comicbookmovie.com/tv/marvel/videos/marvels-the-gifted-official-trailer-v3876

Notice it takes about 10 seconds to load the video assets in the iframe. If you try in chrome 65 or 66, numbers are cut down quite a bit.

Thanks again guys! This seems to be the squad that has the answers.

-- Tommy Williams

On Fri, Jul 6, 2018 at 8:00 PM Tarun Bansal <tba...@google.com> wrote:

Scott, thanks for adding to the thread.

+1 to whatever Scott said. Having an example webpage would be super-helpful.

On Fri, Jul 6, 2018 at 3:53 PM Scott Little <scli...@chromium.org> wrote:

LazyLoad could not have caused those slowdowns. LazyLoad is not launched yet, and it's only intended for Android Chrome. LazyLoad is currently still in the implementation phase, with the currently landed code disabled by default behind a flag.

I'm not sure what caused the slowdowns that you've seen, but perhaps it could be related to Site Isolation, or maybe related to low priority iframes.

Can you explain your numbers? What are they measuring? What are the units (seconds? ms?)? Are these for Chrome desktop users, mobile users, or all of them? Is this an average time, median time, or what?

Can you send a link to an example page where the problem happens?

I've added tbansal@ to this thread since he might have some more context.

--

Tommy Williams

Software Manager

Playwire

1000 E Hillsboro Blvd, Suite 103

Deerfield Beach, FL 33441

 

NOTICE: This e-mail, including attachments, is intended for the exclusive use of the person to whom it is addressed and may contain confidential information. Such information also may be legally privileged. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately.

[Tommy Williams]

I don't know why you're seeing a speedup by hiding your iframe initially, then showing it later. I'd expect it to be the opposite,

EXACTLY! This seems very backwards. But, here we are. The fix is good, it's been testing, deploying on Wednesday. No idea why, but there is something in the code that really messed up 67 and beyond. Like I said, 'lazy load' may be the wrong terminology... I'll check that link you sent and see if it may have something to do with it.

On Mon, Jul 9, 2018 at 7:03 PM Scott Little <scli...@chromium.org> wrote:

Like I said before, LazyLoad could not have caused the slowdowns for 66 and 67 stable users that you mentioned earlier. LazyLoad is not launched yet, and it's only intended for Android Chrome. LazyLoad is currently still in the implementation phase, with the currently landed code disabled by default behind a flag.

I don't know why you're seeing a speedup by hiding your iframe initially, then showing it later. I'd expect it to be the opposite, since as I understand it Chrome does actually throttle the rendering of hidden cross-origin frames to some degree.

On Mon, Jul 9, 2018 at 2:07 PM Tommy Williams <webde...@gmail.com> wrote:

"Deferred iframes": 

Referring to the "Blink LazyFrames" design doc I found in your chormium groups:

https://docs.google.com/document/d/1ITh7UqhmfirprVtjEtpfhga5Qyfoh78UkRmW8r3CntM/edit#heading=h.c7mc4hh4xdhq

This lists 4 points in which an iframe will be deferred. I'm using the option to display: none the iframe until all assets are loaded, and showing the iframe when ready to go, and our player was that was taking ~14s to boot in chrome 67 stable is loading on our devcdn via charles proxy in around ~4s!

I want to re-iterate that LazyLoad is not launched yet, so it's not affecting anything here, unless you've explicitly enabled "Lazy frame loading" in chrome://flags on your testing devices. Otherwise, if you're seeing a speedup by hiding the frame, then it's completely unrelated to LazyLoad.

[Scott Little]

Like I said before, LazyLoad could not have caused the slowdowns for 66 and 67 stable users that you mentioned earlier. LazyLoad is not launched yet, and it's only intended for Android Chrome. LazyLoad is currently still in the implementation phase, with the currently landed code disabled by default behind a flag.

I don't know why you're seeing a speedup by hiding your iframe initially, then showing it later. I'd expect it to be the opposite, since as I understand it Chrome does actually throttle the rendering of hidden cross-origin frames to some degree.

On Mon, Jul 9, 2018 at 2:07 PM Tommy Williams <webde...@gmail.com> wrote:

"Deferred iframes": 

Referring to the "Blink LazyFrames" design doc I found in your chormium groups:

https://docs.google.com/document/d/1ITh7UqhmfirprVtjEtpfhga5Qyfoh78UkRmW8r3CntM/edit#heading=h.c7mc4hh4xdhq

This lists 4 points in which an iframe will be deferred. I'm using the option to display: none the iframe until all assets are loaded, and showing the iframe when ready to go, and our player was that was taking ~14s to boot in chrome 67 stable is loading on our devcdn via charles proxy in around ~4s!

I want to re-iterate that LazyLoad is not launched yet, so it's not affecting anything here, unless you've explicitly enabled "Lazy frame loading" in chrome://flags on your testing devices. Otherwise, if you're seeing a speedup by hiding the frame, then it's completely unrelated to LazyLoad.

 

[Scott Little]

--

Tommy Williams

Software Manager

Playwire

1000 E Hillsboro Blvd, Suite 103

Deerfield Beach, FL 33441