Impact of LINK elements outside the head much worse with ControlJS

126 views
Skip to first unread message

Will Alexander

unread,
Dec 21, 2010, 1:57:04 PM12/21/10
to ControlJS
As you convert pages to use ControlJS, you may find that some actually
take longer to initially render, especially in older browsers (read:
IE 7-). This is probably caused by a <LINK> tag that exists within
the BODY of the HTML. Consider HTML that, before the conversion,
looked like this:

<body>

<!-- lots and lots of images, served from the base domain -->
CONTENT ....
<script src="/script/that/takes/2/seconds/to/deliver.js"> </script>
<link rel=stylesheet href="/css/that/takes/4/seconds.css" />
</body>

Since the SCRIPT tag causes the browser to pause the DOM parsing
process, it does not "see" the <LINK> element below it. Only when the
script finishes does the browser become aware of the new LINK tag.
The browser will paint the screen while it's downloading the script.

When you convert that script to type="text/cjs" the browser ignores it
and therefore knows about the LINK element immediately. You no longer
"benefit" from the 2 second delay that was previously caused by the
script and now will wait to paint until the stylesheet has been
downloaded. The result: Pages will take 4 extra seconds to initially
render.

Downloading a CSS file doesn't usually take 4 seconds; however,
because the LINK is at the bottom of the page, it's added to the end
of the Network queue. Being limited to 2 conns / host, if there are 8
images in the BODY, it will have to wait until 7 of those have
finished before it can start downloading the CSS file. This can
result in a painting delay that is significantly longer than 4
seconds!

Before you convert a page to use ControlJS, make sure you have moved
ALL LINK elements into the HEAD or add them dynamically. But I'm sure
you've all ready done that, right?




Steve Souders

unread,
Dec 21, 2010, 2:23:51 PM12/21/10
to cont...@googlegroups.com, Will Alexander
Hi, Will.

I don't think this is true. The browser parses the HTML, sees the LINK
tag, and blocks rendering (in IE) until the LINK is downloaded
(regardless of the use of ControlJS).

Do you have a test page? Which browsers demonstrates this problem?

-Steve

Will Alexander

unread,
Dec 21, 2010, 2:56:05 PM12/21/10
to ControlJS
I'll add a ControlJS test, but this webpagetest was taken using IE7
against two cuzillion pages shows how the presence of a SCRIPT tag
"hides" LINK elements below it.

http://www.webpagetest.org/video/compare.php?tests=101221_QP_d8986c495befafab50fd5edc2fccfcb7-r:1-c:0,101221_ZQ_3501d51725ddb161086cafcb373cabe6-r:1-c:0

The top one looks like this:

<img 2s delay, domain1>
<img 2s delay, domain1>
<script 4s delay, domain2>
<link 2s delay, domain1>

The page's header is shown immediately and the images display when
they complete (in the 3.5s frame). Since IE stops parsing the DOM when
it encounters the SCRIPT tag, it doesn't "know" there's a LINK element
right around the corner.

The bottom one is identical, except the the SCRIPT tag has been
removed. The pause created by the SCRIPT tag is no longer there and
IE "sees" the LINK element immediately. No rendering occurs until
it's been loaded. The delay is compounded by the fact that the LINK
is added to the front of the queue for domain1, and must wait for one
of the images to complete. If the SCRIPT tag from the first example
is converted to a type of "text/cjs" (or delivered from cache) we'll
see the same behavior.

Will Alexander

unread,
Dec 21, 2010, 3:10:10 PM12/21/10
to ControlJS
IE8 compresses the timeline and displays some of the header, but
overall results are similar: When the script tag is present, the two
images are displayed once they have been downloaded at the 3.5. With
the script tag removed, neither image is displayed until the CSS is
loaded.

http://www.webpagetest.org/video/compare.php?tests=101221_7V_58aa5b00d951a5dc0f07be31f962ad45-r:1-c:0,101221_KX_0b878fba66ac1e204bc81625a328c20e-r:1-c:0


On Dec 21, 2:56 pm, Will Alexander <serverher...@gmail.com> wrote:
> I'll add a ControlJS test, but this webpagetest was taken using IE7
> against two cuzillion pages shows how the presence of a SCRIPT tag
> "hides" LINK elements below it.
>
> http://www.webpagetest.org/video/compare.php?tests=101221_QP_d8986c49...

Will Alexander

unread,
Dec 21, 2010, 3:32:58 PM12/21/10
to ControlJS
Here's a page that converts the script type to "text/cjs"

http://digital-fulcrum.com/controljs/t/outofplacestyle/

These strips include the CJS Script tests. In all cases, the images
finish loading @ 3.5 seconds but they only display @ 3.5s when a
"real" script element exists above the link.

IE7
http://www.webpagetest.org/video/compare.php?tests=101221_QP_d8986c495befafab50fd5edc2fccfcb7-r:1-c:0,101221_ZQ_3501d51725ddb161086cafcb373cabe6-r:1-c:0,101221_9R_248b929edeb38b303fe52ffba9798eb8-r:1-c:0

IE8
http://www.webpagetest.org/video/compare.php?tests=101221_7V_58aa5b00d951a5dc0f07be31f962ad45-r:1-c:0,101221_KX_0b878fba66ac1e204bc81625a328c20e-r:1-c:0,101221_MZ_5834de82005bd464d589ffe2b068458d-r:1-c:0

On Dec 21, 3:10 pm, Will Alexander <serverher...@gmail.com> wrote:
> IE8 compresses the timeline and displays some of the header, but
> overall results are similar: When the script tag is present, the two
> images are displayed once they have been downloaded at the 3.5.  With
> the script tag removed, neither image is displayed until the CSS is
> loaded.
>
> http://www.webpagetest.org/video/compare.php?tests=101221_7V_58aa5b00...

Dave Artz

unread,
Dec 21, 2010, 4:22:10 PM12/21/10
to cont...@googlegroups.com
What's the use case for putting <link> at the bottom of the page?  Just wondering why someone who cares enough about performance to use ControlJS would do such a horrible thing :)

What if you use @import instead of the link? 

<style type="text/css">
</style>

Will Alexander

unread,
Dec 21, 2010, 5:30:17 PM12/21/10
to ControlJS
Just to clarify: This is not an issue with ControlJS, but think this
is a good demonstration of why this rule is important. I've noticed
many sites that, in IE, seem to render faster when un-cached: If the
script that's "hiding" the link delivers from cache, the rendering
that occurs during script load would likely be delayed.

Can't think of why a link at the bottom of the page would be useful,
but can think of a lot of reasons why it might happen :-) Not sure
how the @import would fair.





On Dec 21, 4:22 pm, Dave Artz <davea...@gmail.com> wrote:
> What's the use case for putting <link> at the bottom of the page?  Just
> wondering why someone who cares enough about performance to use ControlJS
> would do such a horrible thing :)
>
> What if you use @import instead of the link?
>
> <style type="text/css">
> @import url("http://1.cuzillion.com/bin/resource.cgi?type=css&sleep=4&n=4&t=129296...");
> </style>
>
> On Tue, Dec 21, 2010 at 3:32 PM, Will Alexander <serverher...@gmail.com>wrote:
>
> > Here's a page that converts the script type to "text/cjs"
>
> >http://digital-fulcrum.com/controljs/t/outofplacestyle/
>
> > These strips include the CJS Script tests.  In all cases, the images
> > finish loading @ 3.5 seconds but they only display @ 3.5s when a
> > "real" script element exists above the link.
>
> > IE7
>
> >http://www.webpagetest.org/video/compare.php?tests=101221_QP_d8986c49...
>
> > IE8

Aaron Peters

unread,
Jan 27, 2011, 11:01:43 AM1/27/11
to ControlJS
This is insightful Will, txs.

Key takeaways:
- DOM parsing stops when browser encounters a normal script tag
<script src="file.js"><script>
- LINK element in the body is bad and makes no sense, but I can
confirm this does happen. Not often, but it happens.
- The @import suggestion is worth looking into, but shouldn't make
difference: the browser won't see it because the DOM parsing stops at
the script tag.


On Dec 21 2010, 11:30 pm, Will Alexander <serverher...@gmail.com>
Reply all
Reply to author
Forward
0 new messages