[chromium-discuss] 3rd party IFrame assets being throttled / lazy-loaded

Discussion:

Tommy Williams

2018-07-06 20:43:30 UTC

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

--
--
Chromium Discussion mailing list: chromium-***@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

---
You received this message because you are subscribed to the Google Groups "Chromium-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discuss+***@chromium.org.

Tommy Williams

2018-07-09 21:07:39 UTC

Permalink

"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!

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

(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.

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
<https://cs.chromium.org/chromium/src/content/public/common/content_features.cc?q=LazyFrameLoading&sq=package:chromium>
.
I'm not sure what you're referring to by "defer iframe assets".

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.

FYI, LazyLoad is *not* enabled by default in Chrome 67 or any version
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 :)

Those are in milliseconds. After writing this email and reading the
documentation further (*https://docs.google.com/document/d/1ITh7UqhmfirprVtjEtpfhga5Qyfoh78UkRmW8r3CntM/edit#heading=h.c7mc4hh4xdhq
<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.
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

Scott, thanks for adding to the thread.
+1 to whatever Scott said. Having an example webpage would be
super-helpful.

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
<https://www.chromium.org/Home/chromium-security/site-isolation>,
or maybe related to low priority iframes
<https://cs.chromium.org/chromium/src/content/public/common/content_features.cc?type=cs&q=kLowPriorityIframes&l=204>
.
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?
context.

Post by 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*
Software Manager
Playwire <http://www.playwiremedia.com/>
1000 E Hillsboro Blvd, Suite 103
Deerfield Beach, FL 33441
https://lh6.googleusercontent.com/NvBTKaX0TcPcvlToXPuSKK5zJkOqeI9AEz3vKVB_Vt3JDEfkce9fg37ecawH6Rsaey3eywEYKuVCP50VDnM3epPDK8ZT4BIW2vWMRT-YHD4G1vs5HpeB1eoXt2nvw8C3s0gZfMwi]
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

2018-07-10 00:21:19 UTC

Permalink

*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.

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
<https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/frame/local_frame_view.cc?sq=package:chromium&q=LocalFrameView::CanThrottleRendering>
.

Post by Tommy Williams
Referring to the "Blink LazyFrames" design doc I found in your chormium
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.

Post by Tommy Williams

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

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.

FYI, LazyLoad is *not* enabled by default in Chrome 67 or any
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 :)

Scott, thanks for adding to the thread.
+1 to whatever Scott said. Having an example webpage would be
super-helpful.

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
<https://www.chromium.org/Home/chromium-security/site-isolation>,
or maybe related to low priority iframes
<https://cs.chromium.org/chromium/src/content/public/common/content_features.cc?type=cs&q=kLowPriorityIframes&l=204>
.
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?
context.
On Fri, Jul 6, 2018 at 1:43 PM Tommy Williams <

Post by 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