↵

How we make RWD sites load fast as heck(filamentgroup.com)

over 9 years ago from Catalin Cimpanu

  • Nice ShoesNice Shoes, over 9 years ago

    I don't fully understand these articles :(.

    But I find them really interesting to the point where I want to understand.

    1 point
    • Daniel EdenDaniel Eden, over 9 years ago

      Web performance can be intense and scary at first, but it's a slippery slope: once you have the bug, you'll spend hours shaving milliseconds off requests. It feels awesome.

      1 point
    • Catalin CimpanuCatalin Cimpanu, over 9 years ago

      You're an art director. You must not concern yourself with ignoble details. Leave these trivial tasks to the puny and unworthy developers :)))

      0 points
    • Jodi WarrenJodi Warren, over 9 years ago

      Here's a slightly simplified version of the article:

      The article talks about techniques to make your website appear as soon as possible on a user's screen. The actual file that the web browser receives should have enough to put something closely resembling your fully loaded site up there. This will make the site feel pretty fast to a user, and is what the article means by perceived performance. This is especially important to users browsing on mobile devices like an iPhone, as they typically have a slower connection and less power than someone on a desktop computer. He wants to shorten the gap between a user trying to access a website and their browser showing the content on screen. He refers to this gap as "the critical path." Shortening this gap is the entire focus of the article.

      He briefly talks about a tool which captures some data about how fast your page loads. He then talks about things that can slow down this initial page render. Loading extra files can increase the aforementioned critical path. The CSS, or webpage styles, are typically stored in a separate file from your content, which is in an HTML file. The Javascript, which is used for most on-page interactivity, also stored in a separate file. This is good because it means that the browser will store, or "cache" the file after the first visit to that website, and then every subsequent page load will be much quicker.

      However, the first time you hit the page, it doesn't have that style information. Almost all CSS files and some JS files are referenced in the top of the HTML page, above the actual content in an area called <head>. The browser will wait to download and read any files referenced in the head before it begins to display the page content. If you've got a complex site with lots of styles and Javascript, this can be a lot of information, and it can produce a perceptible delay, aka the aforementioned critical path. There are a few techniques you can use to reduce the critical path, and he spends the rest of the article talking about them.

      He then talks about some tools that his company maintains which can load CSS files and JS files asynchronously. If something happens asynchronously, it happens alongside other events. This is the opposite of synchronously, where things have to happen in a particular order, and each event has to wait for the previous one to finish. Asynchronous loading of files will mean that it doesn't block the page from displaying content in the time it takes to fetch the CSS and JS.

      The rest of the article talks about ways to pull some of the CSS and Javascript into the HTML page. Inlining CSS and JS means that the browser doesn't have to go off and fetch an additional file before it has enough info to render onto the screen. The downside of this is that it bulks up the size of the HTML file and needs to get loaded every time a user visits a page. He talks about which code is critical for a page to render properly, and is useful to inline.

      The article then talks about a couple of tools than the author maintains. One of them will show you the code used to display the top few hundred pixels - similar to the old above the fold concept.

      The article then suggests trimming out the absolutely essential basic Javascript, and inlining it. The article then talks about another tool, which can sit on the page and give you some useful information about the state of the browser. If you know what you're doing, you can use this information to make some judgements about which further elements to load.

      The article then talks about some smart server code, which checks if your browser has the main CSS and JS files saved. If so, it doesn't bother with the inlining enhancement, making for a faster page load.

      The author then compares a two identical sites, one using these techniques and one not using them. Unsurprisingly, the one using these techniques is substantially faster.

      I hope that was useful and informative. I'm afraid I kind of ran out of time towards the end, so it got a bit glossed over.

      1 point