David Penner, Moboom’s VP of Engineering, spoke about ways of speeding up website rendering at the Moboom 2014 Responsive Web Trends conference in San Francisco. Penner specifically discussed current techniques and their problems.
The conventional approach to performance
As Penner explains, “The size of webpages increased by 25% just last year.” Specifically, he’s referring to the amount of MB that every visitor must download to view the page. He claims that some of this increase is actually due to responsive design. “Now you have long, scrolling pages, which is preferred to having many pages spread throughout the site.”
According to Penner, this trend indicates that webpage size will continue to increase. In his words, “So given that that’s the trend—that’s where sites are going—how do we make the fastest possible sites?”
First, Penner touches on the conventional approach, mentioning that developers can try to use a CDN, make fewer HTTP requests, move stylesheets to the top, move scripts to the bottom, cache, and so on.
While these are good techniques that will have a noticeable effect on page loading, he explains that rather than solve the problem, these are actually just Band-Aids: “Everything you’ve done to this site generally happens post rendering, so it’s like one giant Band-Aid.”
By that he means that these fixes don’t make the site load any faster, and many just make the site appear to load faster.
As Penner explains, “The speed of your pages will ultimately approach a physical limit.” To illustrate this scenario with an example, he describes a sample webpage with several parts: a header, menu, some text, an ad, footer, and so on.
Specifically, your page will be rendered from top to bottom: “It’s going to start with the first part, move on the next part, and go in order all the way through the page, until the page is done and you’re ready to serve it up.” This type of rendering means, “The speed of your page is the sum of all the parts of your page.”
With this method of rendering, as you add more parts to a page, its rendering time increases.
A new approach to rendering
Next, he describes how DevKit handles rendering. First, DevKit separates each part of a page—each heading, block of text, menu, and so on—into widgets. According to Penner, “What we then do is take all of those widgets and run them in parallel—we run them all at the same time. As a result, your page is exactly as fast as the slowest element on your page.”
That means that with DevKit, each element runs at the same time. The DevKitrendering engine combines the output HTML and spits out a webpage in the time it takes to render only the slowest element—rather than the time it takes to render every element one at a time.
The DevKit approach means that if one widget takes 25 milliseconds (ms) to render, and you add 100 widgets that each take 20 ms to render, then the total time to render is still just 25 ms. If you add a 1000 widgets that each take 20 ms to render, then total time is still 25 ms. This works because each widget starts rendering at the same time.
With the conventional approach, pages render from top to bottom, and so those times would be summed instead.