Recently a presentation was made by 2 Googlers (Arvind Jain and Michael Kleber) @ Velocity 2010 where they talked abnout how third party code can slow a website.
Third party code (like Google ads, Digg widget etc.) usually includes an external script. Since browsers block rendering while fetching JavaScript, this third party code also blocks rendering of your page.
Analyse your page with and without this third party component to understand the impact that it has on your site.
If you have an option to choose from multiple vendors, then choose the one which has least impact on your page.
Example: The new Google Analytics code loads JavaScript asynchronously to ensure minimal impact on page loading.
Showing posts with label frontend. Show all posts
Showing posts with label frontend. Show all posts
Sunday, August 01, 2010
Website Performance: Separate Static from Dynamic
A dynamic page is one which can potentially change with each request to the server. But in most cases, there is also some content within these pages which does not change. This content remains static even when the dynamic elements change.
Such static content within a dynamic page varies from application to application but mostly it's stuff like the header, footer, drop-down values (like city, state and country) etc.
Analyse the dynamic page from this angle and come up with a list of static elements on it. If the static elements are considerable (like 30% of the content on a page) then consider separation. There are various techniques which can be used to cache the static elements on the browser.
This approach is useful only when rendering similar layout repeatedly. So, if the same static content (header footer etc.) will be shown for multiple page requests, then separation of static from dynamic is feasible. Whereas, if the static portion changes for each request, there is not much to gain by separation, rather you will end up slowing the existing pages.
Some of the techniques which can be used once the static and dynamic elements are separated:
1) Ajax: A popular and commonly used technique for search result pages. The ajax request is made and only the results are updated whereas the layout remains constant.
2) XSLT (XML+XSL): While requesting for a page, the static elements are embedded in the xsl file and the dynamic elements are fetched using a xml. The xsl can have cache headers defined so that the browser caches it. This is beneficial to the Ajax approach in cases where a new page request is to be made and the user leaves the current page to get content of a new dynamic page. Google for "Browser side XSLT" to get more details on this.
3) HTML in JavaScript as string: This is a simple approach to add html snippets within JavaScript as string so that they can be rendered (inner html) wherever necessary. Not a particularly good design as you will need to add html (view) within the code (javascript).
Such static content within a dynamic page varies from application to application but mostly it's stuff like the header, footer, drop-down values (like city, state and country) etc.
Analyse the dynamic page from this angle and come up with a list of static elements on it. If the static elements are considerable (like 30% of the content on a page) then consider separation. There are various techniques which can be used to cache the static elements on the browser.
This approach is useful only when rendering similar layout repeatedly. So, if the same static content (header footer etc.) will be shown for multiple page requests, then separation of static from dynamic is feasible. Whereas, if the static portion changes for each request, there is not much to gain by separation, rather you will end up slowing the existing pages.
Some of the techniques which can be used once the static and dynamic elements are separated:
1) Ajax: A popular and commonly used technique for search result pages. The ajax request is made and only the results are updated whereas the layout remains constant.
2) XSLT (XML+XSL): While requesting for a page, the static elements are embedded in the xsl file and the dynamic elements are fetched using a xml. The xsl can have cache headers defined so that the browser caches it. This is beneficial to the Ajax approach in cases where a new page request is to be made and the user leaves the current page to get content of a new dynamic page. Google for "Browser side XSLT" to get more details on this.
3) HTML in JavaScript as string: This is a simple approach to add html snippets within JavaScript as string so that they can be rendered (inner html) wherever necessary. Not a particularly good design as you will need to add html (view) within the code (javascript).
Website Performance: Utilize Browser's Idle Time
Once the page loads completely, the user spends few seconds on the page before moving to the next one. The browser is idle during this time and can be used to speed performance of subsequent pages on the website.
For example, in case of search results, it's highly likely that the user will move the the next page once he completes viewing results on the current page. Thus, developers can use intelligent javascript to pre-fetch content of the next page when the browser is idle. This will help the next page load much faster.
Another condition for pre-fetching could be before launching a new version of the site.
New version of a website usually has new static content (javascript, style sheets and images). When a regular user of the site opens this new version for the first time, he will find the site extremely slow. Thus, initially many customers complain about performance.
If we start fetching the static content in the background couple of days before the launch of the new version, customers will not face the slowness and find the performance to be much better. Of course, care has to taken so that there is no clash in names of classes (CSS) and functions (JS).
For example, in case of search results, it's highly likely that the user will move the the next page once he completes viewing results on the current page. Thus, developers can use intelligent javascript to pre-fetch content of the next page when the browser is idle. This will help the next page load much faster.
Another condition for pre-fetching could be before launching a new version of the site.
New version of a website usually has new static content (javascript, style sheets and images). When a regular user of the site opens this new version for the first time, he will find the site extremely slow. Thus, initially many customers complain about performance.
If we start fetching the static content in the background couple of days before the launch of the new version, customers will not face the slowness and find the performance to be much better. Of course, care has to taken so that there is no clash in names of classes (CSS) and functions (JS).
Website Performance: Hosted JavaScript Libraries
Most web applications these days make use of Libraries like jQuery.
These libraries offer significant advantages, but increase the initial page load time to a certain extent.
Most popular libraries are widely hosted by companies like Google and Microsoft. Instead of hosting these libraries yourself, it is feasible to include these libraries from such common locations.
When using the common location, chances are that the Browser has already cached the same URL and need not re-fetch the library for your site.
All in all, it's a win-win situation for you:
1) Saves bandwidth as you need not refer to your hosted library. In some cases this may save you some money.
2) Page loads faster as browsers might already have the libraries cached.
Google Libraries API provides a wrapper around the well known and widely used libraries (jQuery, Dojo, prototype, YUI etc.). Once included, you can directly load any popular library with a simple function call (example: google.load("jquery", "1.4.2"))
These libraries offer significant advantages, but increase the initial page load time to a certain extent.
Most popular libraries are widely hosted by companies like Google and Microsoft. Instead of hosting these libraries yourself, it is feasible to include these libraries from such common locations.
When using the common location, chances are that the Browser has already cached the same URL and need not re-fetch the library for your site.
All in all, it's a win-win situation for you:
1) Saves bandwidth as you need not refer to your hosted library. In some cases this may save you some money.
2) Page loads faster as browsers might already have the libraries cached.
Google Libraries API provides a wrapper around the well known and widely used libraries (jQuery, Dojo, prototype, YUI etc.). Once included, you can directly load any popular library with a simple function call (example: google.load("jquery", "1.4.2"))
Subscribe to:
Posts (Atom)