Sounds nice, doesn't it?
Inspect Element is built into every modern-day browser, so let's try it out on www.akamai.com Just open the site, right click anywhere on the page, and select Inspect Element.
If you're using IE, you'll have to do it their special way instead.
Next up, view the waterfall by clicking on the Network tab:
Refresh the page and notice all of the objects that come up:
I've disabled browser cache to make for a fair analysis. You may wish to check or uncheck that option, depending on your investigation. This can be very helpful in determining which objects are served from browser cache on the repeat load (and more importantly, which objects are not served from cache).
Check out the bottom of the screenshot. There are a total of 84 requests (1.2MB). It loads in 768ms, with DOM content loading in 618ms. Very fast!
You can sort by any column here. Size would be a quick way to determine the largest content on your site, but the most interesting stuff comes from Time (latency). You'll see two numbers next to each object, one in black and one in grey. The black text represents the total time taken for the request. The grey text represents the first byte time. Here, you can quickly see the slowest objects on your page and determine if it's due to server response time (grey) or something else (black). Note: the SSL Negotiation can take up half of your first byte time, if it's not optimized properly. Check this out by clicking the corresponding timeline icon and seeing how much time is taken by SSL activities.
Good news: if you're on Akamai, your first byte times are going to be fantastic, thanks to 150,000 servers in 92 countries within over 1,200 networks.
So let's look at the three slowest loading objects on the page (which are still quite fast):
The final image could be losslessly compressed to save 45KB, but again, this really isn't a dramatic optimization. The site is already speedy.
What about your own website? What are your slowest elements? Can you compress them? Cache them? Grab them from a repository?
It gets even more fun when you run into stuff like render blocking JS/CSS. Basically, these are objects that prevent the rest of the page from loading until they are complete. This can be really unfortunate if the file is slow-loading or blocked by some sort of security policy. It means the whole site will come to a screeching halt until it finishes loading the slow script. And guess what, you can see all of this in the waterfall!
Here's what a good, non-render-blocking script looks like:
Notice how messages.modal.css takes a bit of time to load, but home.css (and other unpictured things) are still allowed to start loading in the meantime. In fact, they're able to finish loading before messages.modal.css does! That's a good thing.
Now here's what a bad, render-blocking script looks like:
See how the next object (and all subsequent objects) can't even start loading until alertcount.json finishes? In 1.23 seconds! That's too slow for a lot of impatient people. And the problem isn't because of that one object. You can have slow-loading objects and give off the illusion of fast load times by asynchronously loading the other content. The problem arises when one object is preventing the entire site from continuing to load. Warning: some scripts need to load before other content, otherwise the page will render incorrectly. You'll need to determine what can load asynchronously and what cannot.
If you have any questions about your own website's waterfall, comment on here and I'll be happy to take a look. For some reason, I find this stuff fun.
Up next, I'll be talking about mobile analysis and optimization. And maybe also some speed tests, like Pingdom and WebPageTest. Feel free to click the "Follow" icon (to the right of this post) to get updates!