CSS and Youtube hackery

Dear Lazyweb, does the calendar seem like it loads slow for you?

I've changed the embedded Youtube videos to use IFRAME instead of OBJECT, with the side-effect that they are now directly playable on iPhones and iPads (the video will play in Safari rather than tossing you over to the Youtube app).

But... I think the page loads slower now. I'm not sure, though. It's hard to tell, and I don't know how to meter it. Do browsers lose their minds if there are a lot of small iframes?

The page has 19 Facebook "Like" iframes, 19 "Google+" frames, 16 Youtube iframes, and 63 images for the various flyer and gallery thumbnails. That doesn't seem like it should count as "a lot" in this modern world, but maybe it does?

Tags: , , ,

63 Responses:

  1. meza says:

    Try populating them with JS after the page loads. (it's just a guess, but might help)

  2. Line Noise says:

    The page loaded very quickly for me in Linux Firefox 5. I got the calendar and all the text rendered first in less than a second. Then the images and videos loaded over the next 5-10 seconds. Considering how slow and oversubscribed my work link is at the moment this is one of the faster pages I've been to recently.

  3. Christian Vogel says:

    For metering, you could use the Opera browser. For debugging web-things it has the dragonfly inspector with a timing-graph. It works with the standard opera install, no extra extensions.

    Load the page, press Ctrl-Shift-I (under Windows... don't know the MacOS shortcut, it's in the main menu under Page > Developer Tools > Opera Dragonfly) and choose the "Network" tab.

    From my current connection (rather slow DSL) it looks as if the thumbnails embedded from dnalounge.com are currently the worst offenders.

    • LionsPhil says:

      And there's FireBug for Firefox, of course. Don't have it enabled right now, but FF3/Win certainly chugs like hell on that page. It's not network-bound, it's CPU---my laptop's cooling fan span up and FF gave up on scrolling, and this is a Core 2, so it's not particularly old or slow.

    • jwz says:

      The Opera inspector is pretty nice, but I don't see any smoking guns there -- also, things seem to load a lot faster in Opera than in Firefox or Safari, which is not good news.

      I tried FireBug, and it seems just as useless and information-free as YSlow is. It has a typical Linux mess of a UI, though, so maybe there's actual information buried in there that I haven't discovered yet. So far all it tells me is "you get an F because your page has a lot of text on it."

      • LionsPhil says:

        You want Firebug's "Net" tab to get the Gannt chart. The big offenders appear to be plusone.google.com to a resource ironically called "fastbutton", some of which still aren't responding after several minutes and some which have aborted, a big chain of G+-related requests, and a big block of YouTube.

        Maybe if you're lucky it's a problem that will go away to some extent on its own if/when Google sort out their servers. You get to trade being unable to fix it for not being responsible for fixing it, yay.

        (Some actual numbers: 231 requests; 6.1 MB (5.7 MB from cache); 49.09s (onload: 26.58s). I'm on a fast link on a fast machine in the UK—89ms to start receiving 08.html. I do have NoScript blocking facebook.com, but the "Like" buttons and their counts still load and appear.)

  4. Roger says:

    I'm currently in Sri Lanka using Linux Chrome. The text part of the page loaded and was laid out quicker than I could switch to the new tab. The images loaded top to bottom taking about a minute before the bottom-most ones completed.

  5. BReed says:

    I'm in Pristina, Kosovo, and it opens just like it normally does. I can't tell you to a dead-on balls-accurate degree of precision because I left my inclinometer in my other pants.

  6. Jake Nelson says:

    Text and layout loaded essentially instantly for me, thumbnails semi-slowly thereafter, youtube after that, mostly.

    Got to say, the non-image/movie parts loaded far, far faster than about 90% of the web... if I didn't know how torturous it is to do, I'd say you should be teaching people how to do this stuff properly...

    Images and movies took a bit, but less time than I'm used to for the quantity. No "too many frames" issues as far as I know.

    Chrome, slowish DSL, midwestern US.

  7. I used Page Speed on it, and it listed a few high priority items to fix: optimize images, defer parsing of JS, and serve scaled images.

    • jwz says:

      These are the same useless answers you get from YSlow -- guesses made without having actually measured anything. E.g., the JS is deferred, and the images are small.

  8. thrax says:

    Works fine for me with FF 3.6 on OS X 10.4

  9. Julien Oster says:

    There is a noticeable issue here. (Linux, Chrome 13, ~16MBit/s DSL)

    Right now, where everything should be cached, I'm observing the following: the site itself (including image thumbnails etc.) appears virtually instantly, minus the embedded videos. But then, there's a period of several seconds where the tab icon still spins its loading animation and input is completely stalled. I can't even scroll down, which is particularly irritating. This period is interrupted by very short opportunities where I can scroll again, but it goes back to stalling almost immediately. Then it goes back to normal and *then* the embedded videos start populating, while I'm perfectly able to scroll (and do other things) again.

    However, even though the embedded videos are only fully populated when everything's responsible again, their areas do start to flash (or turn completely greyish-white) before it gets non-responsive, so I still suspect that's the cause. The fact that the YouTube UI only appears much later might be because of YouTube's applet doing some initialization after being loaded by the browser.

    As I said, it's definitely noticeable here. When I clear the cache before trying, site and images still appear almost immediately, but it takes almost 15 seconds before I'm really allowed to navigate.

  10. Ryan says:

    Would the chrome developer timeline answer this question?

  11. Firefox hangs for a notable second (though hardly egrecious: less than trying to open a PDF, for instance) here on fresh load on my desktop. Firefox on my *phone*, however, which doesn't do plugins, loads it happily, though of course actually clicking any of the videos sends it off to the YouTube app.

    Hats off for having one of the most pleasant mobile-friendly sites around btw (even if the DNA Pizza panorama can't be clicked and dragged when the only input device is a finger).

    - Chris

    • jwz says:

      Dragging the panorama works on iPhone! pano.js line 166. What phone are you using?

      • HTC Desire S. I've just checked on the phone's in-built browser and the panorama drag works fine there, so it's a problem with Mobile Firefox. I'll check again in the unlikely case that the new major release (due in about three days) fixes that.

        - Chris

        • Whaddya know, it actually *does* work in Firefox 6, though because they use "swipe to sides" to reveal UI you've got to push further. Still, progress.

          Chris

  12. Colin says:

    It definitely feels like that page is chugging a bit. It likely also has to do with all the data being downloaded via the iframes. Each one is loading an individual page and each one has it's own javascript and cookie request, which is a lot for a browser to tackle at once. Think of it like having multiple browser windows open at once. And on top of this is the load on the browser from the flash.

    Just downloading all the html/css/javascript is heavy: The Facebook like button HTML/CSS is horribly coded without a ounce of thought at minimization — each one is 48KB which adds up. The html/css/javascript Youtube iframes are also quite large at 86KB — though at least that's a bit more understandable. When you changed to iframes for the Youtube you upped the amount of data that needed to be downloaded tremendously as embeds are small. The Google+1 button html is pretty darn small but still each has javascript with a cookie request.

    • jwz says:

      You'd think/hope that most of this would be cached, though -- even though there are N "like" buttons, they're all pulling in the exact same .js file, right?

      • Colin says:

        You'd think so but nope. The CSS/Javascript is all part of the html and they don't call any external CSS files or script pages so the browser has nothing to cache. Check it out yourself by viewing source on the iframe for the FB like button. The javascript is pretty minimal but the CSS is dreadful with ridiculously long class names and I'd bet tons of unused classes.

        If you use Chrome and run their Audit function it shows one of the problems is 2.11MB of unused CSS. Much of this bulk is due to the fact that the like button doesn't use an external cacheable CSS file.

        • So, my choices are "don't use Like buttons" or "have it suck"?

          I guess I could cut the number of frames in half by deciding that G+ doesn't matter and leaving those out -- but while that is true today, based on the number of clicks we get, it presumably won't be true forever.

          I've seen sites that jump through hoops to only load images and stuff after that part of the page has scrolled into view, but that sounds both hard and really flaky...

  13. It does take a while - I wonder if it's opening a brand new connection for each one, rather than reusing them more sensibly.

  14. daphne says:

    15 seconds. Firefox. 512 kb/s.

  15. Colin says:

    Speaking of download weight. Your flyer thumbs are larger than they should be for a jpg that size for some reason. Not sure how much this is affecting the page load as a whole but I thought I'd point it out. The worst offender is the Trannyshack Kate Bush thumb which is a whopping 598KB: http://www.dnalounge.com/flyers/2011/08/19-1-thumb.jpg. I have no idea how that jpg file can even be that big.

    • jwz says:

      Oh, geez. There's all kinds of bullshit in the EXIF, looks like.

    • it's a 1200x1800 pix image at 300dpi (which is why it's the size of a thumbnail Safari will display/honour the image at the EXIF dpi)

      • relaxing says:

        What did you use to determine this?
        Gimp tells me "Number of pixels: 21600" which doesn't seem like something it would make up based on PPI metadata.

        Looking at the file in a hex editor is... bizarre. My hypothesis is the extra data is due to an embedded ICC profile called "U.S. Web Coated (SWOP) v2"...

        Or steganography.

        Tranny steganography.

        SWOP.

      • jwz says:

        Almost. The image itself was 120x180px, but it apparently had a 1200x1800 300dpi "preview" in the EXIF, because it began its life as a PDF and I forgot to add "-strip" to "convert".

  16. no one, really says:

    Sorry to say, it's slow as fuck. Took like 30 seconds, freezing my Opera for 10 in the process (although my computer has probably less oomph than those iPhones you tested it on...).

  17. mrbill says:

    Try testing with this Google Labs tool:

    http://pagespeed.googlelabs.com/

    • jwz says:

      Someone already suggested that, and as I wrote above, that's the same useless crap that YSlow reports without actually measuring anything.

      • mrbill says:

        Do you have live before & after URLs to compare?

          • mrbill says:

            Quick look at your site looks like your web server is not configured to use keep-alives - so we've got like 67 network round trips to http://www.dnalounge.com alone just for that URL. Changing this will help somewhat.

            In total, this page downloads 1.8mb of data - a fair chunk.

            Without seeing the original page, i'm not sure what to compare it to - but either way, enabling keepalives on will help considering the number of objects on this page.

  18. Paul says:

    Too many Adobe Flash instances?

    It loads okay for me on Vista+Chrome+3GB RAM, but the Chrome task manager says the Adobe Flash plugin is using 133MB memory and rising. Closing the tab releases most of this. I've had pages filled with YouTube videos freeze up my browser.

  19. What you need to do is look at the "Network" tab in any browser's debugger. They all have one. In chrome: inspect element: network- then reload the page. In safari, same. In firebug: the net tab. These will show you a gantt chart of the page load timeline. Just having a quick look at your source myself, you are /not/ deferring your javascript. what I see is the base HTML takes nearly 2 seconds to load- which is /a lot/. you should be aiming for closer to 20-80ms. This breaks down to 970ms of just /waiting/ for the html. 575ms of actual downloading. This latency could just likely be due to me being on the ass end of the planet. Then we get to the meaty stuff:

    In the gantt chart what you should should be looking for is a cascade of dependencies-> Files that cannot load until another file completely loads /first/ I am definitely seeing a cascade here, though it's not clear to me what exactly depends on what. . Absolutely /nothing/ can load until after every single javascript file has completely loaded, parsed and executed, which is why it's a bad idea to have them in the head, as you have. We don't finish with javascript loading until the 3 second mark, and nothing else even starts until that's done. This is especially important if you're loading JS from third party servers, whose latencies tend to be rather variable. THEIR slowness, can easily bring YOUR whole page to a crawl.

    then a bunch of images load. The last image load starts at 4 seconds.

    There's an iframe, i think, somewhere that is loading in /blog/index.php , which doesn't load until after everything else, and all of ITS dependencies can't load, until it loads.

    It's a bit of a mess, I'm sorry.

  20. OH god, sorry. I'm looking at the wrong page. Let me try this again.

  21. Okay, this time, looking at the /correct/ page- A zillion iFrames= misery. a bunch of stuff does get pulled from the cache, but there's still a certain amount of latency and overhead in just fetching these files from the cache, again and again, from separate sandboxed rendering contexts-, and it just adds up. You can see happening in the timeline chart. If a file is in an iframe, apparently the browser doesn't re-use the same in memory representation of the file, it's gotta load it from the cache again each time.

    • jwz says:

      I don't believe that the problem is the loading of images from my server, so I doubt keepalive will fix that. It looks to me like the images load first, and relatively quickly, and then everything goes to crap trying to process the "Like" buttons and videos. (I have it off because at some point I gained the impression that turning keepalive on was a great way to kill Apache's performance, but I don't remember where I got that idea.)

      In any event, I'm not really interested in answering the question, "is it slower today than it was yesterday." I only care about, "how do I make it be faster than it is now."

      So far, the only plausible option I've seen is, "don't put 40 Like buttons on that page". That's not really a great option.

      • mrbill says:

        Keepalives actually improve server performance - why don't you try enabling them - if only temporarily.

  22. Io would suggest finding a way to embed this stuff without iframes some how- server side transclusion, whatever. Interact with these Apis in some way that doesn't involve iframes. I'd offer more help but I'm at work.

    • jwz says:

      As far as I am aware, there is no way to do either a Facebook or Google "Like" button without an iframe. (Those other syntaxes they have like <fb:like> end up emitting an iframe underneath.)

      It's still possible (for now) to embed Youtube videos using <object> instead of iframe, but if you do that, the videos don't play on iphone.

      • Shay says:

        Might be a dumb question, but can't you copy the content of the iframe to the page itself? Haven't had a chance to look at the new youtube embeds, I'm assuming the iframe contains some kind of device or flash detection js that either embeds the same flash object you'd see normally on a desktop, or renders the youtube html5 player.

        Also, you might find this useful: http://www.webpagetest.org/result/110819_YF_1C54X/

  23. My spirit of never say never and ingenuity tells me there must be *some* way. But my spirit of "not pissing off my boss" will force me to wait a few more hours before I indulge that first spirit .

  24. For reference later, what technologies are available on the server hosting that page? Php? Ssi?

  25. I just thought of something. You can use this for the YouTube videos to get your iPhone support http://sandbox.thewikies.com/vfe-generator/

  26. Videosift.com used to show the full youtube videos on it's listing pages, but they eventually did away with it because of the flash and loading overhead. now it shows a cached thumbnail, and creates the youtube iframes dynamically via some JS or AJAX, so it only loads from youtube when the user selects it.

  27. Vitorio says:

    JS performance book authors Amy Hoy and Thomas Fuchs wrote a bookmarklet called DOM Monster which analyzes your page structure and offers performance improvement suggestions. For your linked calendar page, it has two warnings, along with a bunch of suggestions:

    WARN Element count seems excessively high. Performance might improve if you reduce the number of nodes.
    WARN Reduce the number of <iframe> tags There are 54 iframe elements on the page.

    So, yes, perhaps all those iframes really are bad. You are loading up an entirely new document tree in each one, after all.

    • jwz says:

      "Yet another clone of YSlow tells me that the page is big, and has a bunch of Like buttons on it" is, again, not news, and, again, not useful information.

  28. Aside from using the V4E markup for youtube videos (instead of iframes), here's another option: Replace all your like buttons with static images, and use a tiny bit of javascript to replace the button with the iframe when the user clicks/hovers/scrollsto/looksat the button. That way, rather than taking all that loading up front, you're spreading it out.

    con: you don't see like/+1 counts until the button gets replaced.

    pro: your page doesn't take 10 years to load.

  29. here is something slightly more substantial than a guess. in safari I use this extension called youtube5 http://www.verticalforest.com/youtube5-extension/

    when installed, it transparently replaces all the youtube embeddings in your calendar page with equivalent pure html5/video tag things- The result is essentially the same as if you yourself replaced all your youtube embeddings with the v4e embedding I recommended above. The result is that with the extension installed, the page loads much much faster. (aside from the like buttons)

    This I suppose is a data point in favour of replacing your youtube embeddings with v4e.

  30. Christopher says:

    In Chrome 15.0.854.0 dev on a four year-old MacBook, with FlashBlock enabled, it seems to layout the HTML quickly but I'm unable to scroll down for at least 20 seconds. Then it either works or I eventually get a "this page is not responding" popup.

    Other pages chock-full of JS and whatnot are currently loading fine.