In the field of web performance, professionals would suggest that the critical render path is an important concept. What is the critical render path? Basically, it’s the code and resources required to render an initial view of a web page. The rendering path can be viewed as the chain of events that occur to make your webpage appear on a browser. The “critical” aspect would integrate only the most important components to render only the initial view of your webpage. In order to display a simple web page, the browser goes through a series of steps to get the resources it needs to display a web page:

  1. Browser downloads the html file

  2. Browser reads the html and sees that there are one css file, one javascript file and one image

  3. Browser starts downloading the image

  4. Browser decides it can not display the webpage without first getting the css and javascript

  5. Browser downloads the CSS file and reads it to make sure nothing else is being called

  6. Browser decides it still can not display the webpage yet until it has the javascript

  7. Browser downloads the javascript file and reads it to make sure nothing else is being called

  8. Browser now decides it can display the webpage

Although the path is simplified, many websites out there have numerous social buttons, several CSS files, several javascript files, many images, and maybe a few audio or videos. This can result in the render path being huge and complicated. Most websites have absolutely terrible render paths because they are calling so many things that the browser must load before the webpage can be displayed.

Two types of resources that webpages call that generally block the render of webpages are the CSS files and the javascript files. No matter how many of these you have, the browser must download and parse each and every one of these files before it can show anything at all to the user.

To better optimize a web page, be sure to focus on the “critical” aspect of what makes your site important. If you have over 1000 pictures and 200 javascript files, focus on the resources that are required to render the initial view of your web page.

Start by prioritizing the content on your web page, followed by deferring certain javascript files until after the pageload.  By optimizing the critical path, you can reduce all those calls to one request. All the browser needs to render this page is the html file.

For an in depth view, read more at http://bit.ly/1hJDsLY

Utilising Response Web Design

Responsive Web Design is becoming an established technique yet it’s adoption is still not being executed. Often when responsive sites are designed, the approach is primarily from a visual design perspective with little attention towards performance concerns. Fortunately, here are some techniques to develop a strong performance site that caters to the visual scale while delivering  codes and assets tuned to mobile optimization.

14KB on Mobile

First impressions do count. While it’s easy to throw jQuery, a framework like Bootstrap/Foundation and web fonts on a page you trade ease of use for performance. It’s increasingly a mobile world and your main aim should be to engage users as quickly as possible.

At a recent Velocity conference, Ilya Grigorik’s highlighted what it takes to deliver a mobile page within one second. Users get one HTTP request and only 14kb of HTML to work with in order to get content in front of users. One of the only ways to achieve this is by inlining any “above the fold” CSS and JS required to render the first screen of content.

Compressing CSS and JS

Tools like modpagespeed and CloudFlare can help with front-end optimization. Responsive sites generally combine the desktop and mobile CSS and JS into one set of files. This results in presenting a poor code to the width users are viewing. This can be optimized by using javascript to detect the width of the page. Once detected, you can request the style and javascript appropriate to the size of width.

Shrinking images

When visiting a web page, images are the largest assets on a page. Remember to serve the right image to the proper width and being able to art direct the image for smaller screen sizes by cropping into the focal point of an image for smaller widths. Another way is to simply eliminate an image altogether by using a tool like icon font or SVG images. Both these tools use vector data so they are small in file size and scale efficiently across all sizes including high resolution retina screens.

Case study: Guardian Site

“A great example using the above techniques is the new Guardian newspaper website, currently inalpha. On average it’s start render time is 3 seconds faster than the current Guardian site and the mobile width inlines CSS and is 42% smaller overall, leading to a 1 second saving over the desktop width.”

Read more at http://bit.ly/19QlW6K

HTTP Published End of the Year Statistics

HTTP Archive Report has published their end-of-year technology statistics which collects information from 300,000 of the web’s most popular websites. The average page weight has increased by 32%. Some of the increase can be explained by the increasing ecommerce activity and advertising as people hunt for gifts. However, few websites lose weight in January and continue to gorge themselves throughout the year.

The report analyzes publicly-accessible content and shopping web sites rather than provides a breakdown of the specific technologies used:

Technology

End 2012

End 2013

Increase

HTML

54Kb

57Kb

+6%

CSS

35Kb

46Kb

+31%

JavaScript

211Kb

276Kb

+31%

Images

793Kb

1,030Kb

+30%

Flash

92Kb

87Kb

-5%

Other

101Kb

205Kb

+103%

Total

1,286Kb

1,701Kb

+32%

The Reasons

Bloated CMS Templates

Typical WordPress themes are crammed full of features. Many will be third-party styles and widgets the author has added to make the theme more useful or attractive to buyers. Many features will not be used but the files are still present.

HTML5 Boilerplates

A boilerplate may save time but it’s important to understand they are generic templates. The styles and scripts contain features you’ll never use and the HTML can be verbose with deeply-nested elements and long-winded, descriptive class names. Few developers bother to remove redundant code.

Carelessness

Developers are inherently lazy; we write software to make tasks easier. However, if you’re not concerned about the consequences of page weight, you should have your web license revoked.

Read more at http://bit.ly/1cBOLpT

Similar Posts