Waiting status caused by incorrect placement of elements? NSFW

Question

---

NSFW: Please be aware the site sells cannabis seeds, so the link is NSFW.

---

I have a few websites which run on the same or very similar systems and they all run very quickly apart from one and I am unable to figure out why, I am sure this is mainly down to my inexperience but I have looked through Firebug's Net tab and I'm not sure I quite understand it.

I can see that one of the fast websites has a size and content of 80.33kb for a product page and this takes 1.28s of waiting and 598ms of loading to display and the slow website has a size of 22.87kb and a content of 158kb and has a latency of 4.75s with 4.55s of that being waiting.

I would really like to know how to reduce this waiting time and why the size and content figures are so different. You can see the problem at this page.

Answer 1

You have a veritable crap-tonne of JavaScript all the way through the page.

The goal is to load as much as physically possible without using JS at all, and then do all of your JS-loading at the very bottom.

You've also got a LOT of different JS scripts. Like... really a lot.

You might consider figuring out what order they need to appear in, and then paste them in that order, into one single file (or a half-dozen, or whatever, but Google is suggesting that there are dozens of JS files on that one page), and then load that at the bottom of the page.

This might mean that you need to learn a little more about deferring the loading of things on your page, and it might mean that you need to learn how to separate concerns a little more (I didn't look further than your flags to see that every one had an onclick handler, which undoubtedly does something huge -- better to add one single listener to the container holding all of the flags, and then identify which one it was and run from there).

But when a JS file downloads, the browser pauses and compiles it all. This is usually a fraction of a second. But if you have dozens of files lined up, one after the other, it's a pause to load the file, a pause to access the file-contents, a pause to compile the JS in the file, and then it runs the JS, before moving on to showing the next part of the site...

So all of those little pauses are adding up.

That's why you should serve just the JS you need, and you should serve it at the bottom of the page, and then load in the nice-to-have stuff a little after that. Compiling a single file with hundreds of lines of code, even, would take less time than compiling 10 files that only have dozens of lines.

In the end, it comes down to what the user SEES happening, and not how fast the downloads are benchmarked at.

Answer 2

Looking at the page loads using the Chrome Network tab in Developer Tools, I receive the following timings at the following link:

http://www.seed-city.com/barneys-farm-seeds/liberty-haze

102 requests | 131.24KB | 8.41s (onload: 8.50s, DOMContentLoaded: 6.61s)
102 requests | 131.47KB | 8.47s (onload: 8.56s, DOMContentLoaded: 6.82s)
102 requests | 131.45KB | 8.71s (onload: 8.79s, DOMContentLoaded: 7.06s)

Now, making one (somewhat simple) change:

103 requests | 110.16KB | 3.77s (onload: 3.86s, DOMContentLoaded: 2.03s)
103 requests | 110.17KB | 3.85s (onload: 3.94s, DOMContentLoaded: 2.21s)
103 requests | 110.16KB | 4.20s (onload: 3.50s, DOMContentLoaded: 2.28s)

Here is a typical HAR log outputted from the Network tab for your current page:

http://pastebin.com/pM5Dd1Fw

The important part is to realize the browser is waiting nearly five seconds to even do anything (snipped only to show the relevant lines):

{
  "startedDateTime": "2012-09-29T04:58:07.861Z",
  "time": 4831,
  "request": {
    "method": "GET",
    "url": "http://www.seed-city.com/barneys-farm-seeds/liberty-haze",
    "httpVersion": "HTTP/1.1",
    ...
  },
  "cache": {},
  "timings": {
    "blocked": 0,
    "dns": 16,
    "connect": 129,
    "send": 0,
    "wait": 4677,        // <<< Right here
    "receive": 8,
    "ssl": -1
  }
}

And the timing for the slow.html page:

{
  "startedDateTime": "2012-09-29T05:04:51.624Z",
  "time": 92,
  "request": {
    "method": "GET",
    "url": "http://example.com/t/slow.html",
    "httpVersion": "HTTP/1.1",
    ...
  },
  "timings": {
    "blocked": 0,
    "dns": 7,
    "connect": 38,
    "send": 0,
    "wait": 44,           // <<< Right here
    "receive": 1,
    "ssl": -1
  },
  "pageref": "page_3"
}

That's 4677ms vs 44ms. Here is a typical HAR log for that updated page:

http://pastebin.com/Jgm1YyU3

So what did I do to achieve those (very real and tangible) improvements? I moved the Javascript to the bottom of the body tag:

http://pastebin.com/H9ajG99H

This makes a two-fold improvement. First, you're allowing the browser to continue and get your content loaded before it starts interacting with blocking processes (the script calls). So your customers will "notice" a speedier site, simply because the page seems to load faster (when really you're just allowing it to load as it goes). Second, you wait until the body tag is essentially fully loaded before you start monkeying with it's content.

It also looks like you're not using cache directives in your headers that tell the browser not to check for an update to a file for so long. So your Twitter and Facebook icons, it looks like the browser thinks it needs to recheck with the server, making a round trip that should, in theory, be unnecessary except only so often. But the time spent "waiting":

twitter_aqu_64.png 1.32s
ajax-loader.gif    1.31s
ssl-icon.jpg       1.31s

Now, I'm not an expert in cache-control; it's a little bit of a dark art. But those timings make me think there may be something going on there.

Try this answer for more information on cache-control:

HTML Cache control