Namespaces

Variants
Actions

Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries over the next few weeks. Thanks for all your past and future contributions.

(Difference between revisions)

High performance Widgets: Optimize your JavaScript

From Wiki
Jump to: navigation, search
jimgilmour1 (Talk | contribs)
m (Trade smoothness for speed: spelling)
hamishwillee (Talk | contribs)
m (Text replace - "Category:Mobile Design" to "")
 
(7 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[[Category:Mobile_Design]]
+
[[Category:Symbian Web Runtime]][[Category:Mobile Design Patterns]]
[[Category:Mobile_Design_Patterns]][[Category:Web Runtime (WRT)]]
+
{{ArticleMetaData <!-- v1.1 -->
 +
|sourcecode= <!-- Link to example source code e.g. [[Media:The Code Example ZIP.zip]] -->
 +
|installfile= <!-- Link to installation file (e.g. [[Media:The Installation File.sis]]) -->
 +
|devices= <!-- Devices tested against - e.g. ''devices=Nokia 6131 NFC, Nokia C7-00'') -->
 +
|sdk= <!-- SDK(s) built and tested against (e.g. [http://linktosdkdownload/ Qt SDK 1.1.4]) -->
 +
|platform= <!-- Compatible platforms - e.g. Symbian^1 and later, Qt 4.6 and later -->
 +
|devicecompatability= <!-- Compatible devices e.g.: All* (must have internal GPS) -->
 +
|dependencies= <!-- Any other/external dependencies e.g.: Google Maps Api v1.0 -->
 +
|signing= <!-- Signing requirements - empty or one of: Self-Signed, DevCert, Manufacturer -->
 +
|capabilities= <!-- Capabilities required by the article/code example (e.g. Location, NetworkServices. -->
 +
|keywords= <!-- APIs, classes and methods (e.g. QSystemScreenSaver, QList, CBase -->
 +
|id= <!-- Article Id (Knowledge base articles only) -->
 +
|language= <!-- Language category code for non-English topics - e.g. Lang-Chinese -->
 +
|translated-by= <!-- [[User:XXXX]] -->
 +
|translated-from-title= <!-- Title only -->
 +
|translated-from-id= <!-- Id of translated revision -->
 +
|review-by= <!-- After re-review: [[User:username]] -->
 +
|review-timestamp= <!-- After re-review: YYYYMMDD -->
 +
|update-by= <!-- After significant update: [[User:username]]-->
 +
|update-timestamp= <!-- After significant update: YYYYMMDD -->
 +
|creationdate= 20090523
 +
|author= [[User:Feliperodrigues]]
 +
}}
 +
 
 
==Introduction==
 
==Introduction==
  
This article is the number three of the series, '''High performance Widgets''', and continues what we started in [http://wiki.forum.nokia.com/index.php/Mobile_Design_Pattern:_High_Performance_Widgets:_CSS_Sprites High Performance Widgets: CSS Sprites] and [http://wiki.forum.nokia.com/index.php/High_performance_Widgets:_Combine_your_JavaScripts_and_CSS_in_external_Files  High performance Widgets: Combine your JavaScripts and CSS in external Files] .
+
This article is the number three of the series, '''High performance Widgets''', and continues what we started in [[Mobile Design Pattern: High Performance Widgets: CSS Sprites|High Performance Widgets: CSS Sprites]] and [[High performance Widgets: Combine your JavaScripts and CSS in external Files]] .
  
 
JavaScript are getting more important every day. They have broken the web barrier and now are used in different platforms, such as our beloved WRT. To supply these new needs, the applications are getting larger, more complex and sophisticated. But if not watched, this sophistication can cost you a slow performance for your app, widget or website.
 
JavaScript are getting more important every day. They have broken the web barrier and now are used in different platforms, such as our beloved WRT. To supply these new needs, the applications are getting larger, more complex and sophisticated. But if not watched, this sophistication can cost you a slow performance for your app, widget or website.
Line 10: Line 33:
  
 
There are millions of techniques to speed up your JavaScript. The objective of this article is to show some of this tips, that when applied to your Widgets or mobile websites, will help you to make it faster and better for the user experience.
 
There are millions of techniques to speed up your JavaScript. The objective of this article is to show some of this tips, that when applied to your Widgets or mobile websites, will help you to make it faster and better for the user experience.
 
 
----
 
  
 
== Watch your DOM ==
 
== Watch your DOM ==
Line 39: Line 59:
 
[http://www.youtube.com/watch?v=ZTnIxIA5KGw Gecko Reflow Visualization - mozilla.org]<br/>
 
[http://www.youtube.com/watch?v=ZTnIxIA5KGw Gecko Reflow Visualization - mozilla.org]<br/>
 
[http://www.youtube.com/watch?v=dndeRnzkJDU Gecko Reflow Visualization - Wikipedia]
 
[http://www.youtube.com/watch?v=dndeRnzkJDU Gecko Reflow Visualization - Wikipedia]
 
 
----
 
  
 
== Good with them, better off without them. ==
 
== Good with them, better off without them. ==
Line 50: Line 67:
  
 
Notice that some elements have significantly slower reflows than others. Reflowing an element with table display, can take as much as three times as long as reflowing an equivalent element with block display
 
Notice that some elements have significantly slower reflows than others. Reflowing an element with table display, can take as much as three times as long as reflowing an equivalent element with block display
 
 
----
 
 
  
 
==Apply animations to elements fixed or absolute.==
 
==Apply animations to elements fixed or absolute.==
  
 
Elements which are positioned as Fixed or absolute don’t affect the document or other elements layout, so they will only cause a repaint instead of a total reflow. This is much lighter and better for your widget.
 
Elements which are positioned as Fixed or absolute don’t affect the document or other elements layout, so they will only cause a repaint instead of a total reflow. This is much lighter and better for your widget.
 
 
----
 
  
 
== How to get rid of them==
 
== How to get rid of them==
Line 66: Line 76:
 
Another common source of multiple reflows is making changes to an element’s appearance via the '''Style''' (CSS in case you're using jQuery) property. For example:
 
Another common source of multiple reflows is making changes to an element’s appearance via the '''Style''' (CSS in case you're using jQuery) property. For example:
  
<code lang="javascript">
+
<code javascript>
  
 
//Style Changes using jQuery
 
//Style Changes using jQuery
Line 73: Line 83:
 
$('element').css('backgroundColor','#CCC');
 
$('element').css('backgroundColor','#CCC');
 
$('element').css('fontSize', '13px');
 
$('element').css('fontSize', '13px');
 
 
 
</code>
 
</code>
 
This jQuery code has three style changes, what gives us three reflows. Each reflow happens linked to every change in the style of this element. The solution to keep reflows at minimum in this case, is to group all this changes in a new CSS class, and than use the jQuery or JavaScript to change the class.  
 
This jQuery code has three style changes, what gives us three reflows. Each reflow happens linked to every change in the style of this element. The solution to keep reflows at minimum in this case, is to group all this changes in a new CSS class, and than use the jQuery or JavaScript to change the class.  
Line 80: Line 88:
 
Example:
 
Example:
  
<code lang="css">
+
<code css>
 
     /*The same changes now are in the CSS*/
 
     /*The same changes now are in the CSS*/
  
Line 92: Line 100:
 
Then you reduce the javaScript to one line.
 
Then you reduce the javaScript to one line.
  
<code lang="javascript">
+
<code javascript>
 
$('element').addClass('newStyle');
 
$('element').addClass('newStyle');
 
</code>
 
</code>
  
 
Changing the class of an element counts allows all of the styles to be applied at once, within a single reflow. This is much more efficient and also more maintainable in the long run.
 
Changing the class of an element counts allows all of the styles to be applied at once, within a single reflow. This is much more efficient and also more maintainable in the long run.
 
 
----
 
  
 
== Trade smoothness for speed ==
 
== Trade smoothness for speed ==
Line 107: Line 112:
 
It can be neccessary to swallow the developer pride, and trade some of the smoothness of the animation for speed instead.
 
It can be neccessary to swallow the developer pride, and trade some of the smoothness of the animation for speed instead.
 
The sophisticated animations, may make your widget look slow, because it will need much more processing power. That is a bad response to the user. I recomend you to use the simple Hide/Show jQuery Solution, which is a less smooth solution, but is the fastest response your user can get on lower powered processors.
 
The sophisticated animations, may make your widget look slow, because it will need much more processing power. That is a bad response to the user. I recomend you to use the simple Hide/Show jQuery Solution, which is a less smooth solution, but is the fastest response your user can get on lower powered processors.
 
 
----
 
  
 
== Reference ==
 
== Reference ==
  
 
See another tips about good JavaScript pratices in:
 
See another tips about good JavaScript pratices in:
 
+
* [http://dev.opera.com/articles/view/efficient-javascript/ Opera.Dev]
[http://dev.opera.com/articles/view/efficient-javascript/ Opera.Dev]
+
* [http://www-archive.mozilla.org/newlayout/doc/reflow.html Mozilla.org]
 
+
* [http://www.stubbornella.org/content/2009/03/27/reflows-repaints-css-performance-making-your-javascript-slow/ Reflows & Repaints: CSS Performance making your JavaScript slow?]
[http://www.mozilla.org/newlayout/doc/reflow.html Mozilla.org]
+
 
+
[http://www.stubbornella.org/content/2009/03/27/reflows-repaints-css-performance-making-your-javascript-slow/ Reflows & Repaints: CSS Performance making your JavaScript slow?]
+
 
+
 
+
----
+
 
+
  
 
==Tools==
 
==Tools==
  
* [http://ua-profiler.appspot.com/reflows/ Lindsey Simon wrote a bookmarklet for you to test reflows in any browser.]
+
* [http://code.google.com/speed/articles/reflow.html Lindsey Simon wrote a bookmarklet for you to test reflows in any browser.]
 
* [http://ejohn.org/blog/browser-paint-events/ John Resig's bookmarklet to visualize paint events.]
 
* [http://ejohn.org/blog/browser-paint-events/ John Resig's bookmarklet to visualize paint events.]
 
 
----
 
  
 
==See Also==
 
==See Also==
  
[http://wiki.forum.nokia.com/index.php/Mobile_Design_Pattern:_High_Performance_Widgets:_CSS_Sprites High Performance Widgets: CSS Sprites]
+
* [[Mobile Design Pattern: High Performance Widgets: CSS Sprites|High Performance Widgets: CSS Sprites]]
<br/>
+
* [[High performance Widgets: Combine your JavaScripts and CSS in external Files]]
[http://wiki.forum.nokia.com/index.php/High_performance_Widgets:_Combine_your_JavaScripts_and_CSS_in_external_Files  High performance Widgets: Combine your JavaScripts and CSS in external Files]
+

Latest revision as of 06:06, 16 April 2012

Article Metadata
Article
Created: User:Feliperodrigues (23 May 2009)
Last edited: hamishwillee (16 Apr 2012)

Contents

[edit] Introduction

This article is the number three of the series, High performance Widgets, and continues what we started in High Performance Widgets: CSS Sprites and High performance Widgets: Combine your JavaScripts and CSS in external Files .

JavaScript are getting more important every day. They have broken the web barrier and now are used in different platforms, such as our beloved WRT. To supply these new needs, the applications are getting larger, more complex and sophisticated. But if not watched, this sophistication can cost you a slow performance for your app, widget or website.

Like Joseph Smarr said, Performance is something that you need to take seriously from the day one. If you don’t, may be too late when you find out.

There are millions of techniques to speed up your JavaScript. The objective of this article is to show some of this tips, that when applied to your Widgets or mobile websites, will help you to make it faster and better for the user experience.

[edit] Watch your DOM

Well, DOM interaction is not fast. I know that, and you know that. The Document Object Model can run slowly by different motives. One of the most common things that make your JavaScript slow is when too much things happen inside your DOM, like redrawing or reflows.

[edit] Redraw

Redraw is when the DOM changes the User interface in real time, like changing the background color, or the visibility of elements, effects that are frequently used by widgets developers. These DOM changes demands a lot of loading process, since it requires to the JavaScript to search all elements to determinate and execute them. That’s why they're so heavy to load.

[edit] Reflow

Reflow is one of the most expensive functions of a browser. This is a far more significant change. The reflow happens when:

  • When you add or remove a DOM node.
  • When you apply a inline style.
  • When you get a measurement or info that must be calculated, such as accessing offsetWidth, clientHeight, or any computed CSS value (via getComputedStyle() in DOM-compliant browsers or currentStyle in IE), while DOM changes are waiting to be made.


After any of these examples above, the engine must then reflow all the related elements to work out which and where the various parts of it should now be displayed. Its children, Ancestors and all the elements that appear after it in the DOM tree, will alson be reflowed to calculate their new layout, as they may have been moved by the initial reflows. After all this processes, finally, everything is redrawed.

[edit] Visualize Redraw and Reflow examples

This videos, show how the Redraw and Reflow process works on the web browser.

Gecko Reflow Visualization - mozilla.org
Gecko Reflow Visualization - Wikipedia

[edit] Good with them, better off without them.

Reflows and Redraws, affect the whole widget performance, because they affect the whole document. The more it happens, the longer the document will take to make all the changes.

Reflows something, that developers should keep at minimum, as long as they want to make their scripts running fast. But, Though animations, transitions and stuff are all based on reflows, we still want them to make our app prettier.

Notice that some elements have significantly slower reflows than others. Reflowing an element with table display, can take as much as three times as long as reflowing an equivalent element with block display

[edit] Apply animations to elements fixed or absolute.

Elements which are positioned as Fixed or absolute don’t affect the document or other elements layout, so they will only cause a repaint instead of a total reflow. This is much lighter and better for your widget.

[edit] How to get rid of them

Another common source of multiple reflows is making changes to an element’s appearance via the Style (CSS in case you're using jQuery) property. For example:

//Style Changes using jQuery
 
$('element').css('color','red');
$('element').css('backgroundColor','#CCC');
$('element').css('fontSize', '13px');

This jQuery code has three style changes, what gives us three reflows. Each reflow happens linked to every change in the style of this element. The solution to keep reflows at minimum in this case, is to group all this changes in a new CSS class, and than use the jQuery or JavaScript to change the class.

Example:

    /*The same changes now are in the CSS*/
 
.newStyle {
 
background-color: #CCC;
color: red;
font-size: 13px;
}

Then you reduce the javaScript to one line.

$('element').addClass('newStyle');

Changing the class of an element counts allows all of the styles to be applied at once, within a single reflow. This is much more efficient and also more maintainable in the long run.

[edit] Trade smoothness for speed

Means that you should choose the best option for your user. As tempting as making a smooth animation transition can be, you should set them to animate the fastest as you can. Instead of setting the transition animation using a 1 pixel(10ms) at a time you shoul try something less smooth, like a 5 pixels (50ms).

It can be neccessary to swallow the developer pride, and trade some of the smoothness of the animation for speed instead. The sophisticated animations, may make your widget look slow, because it will need much more processing power. That is a bad response to the user. I recomend you to use the simple Hide/Show jQuery Solution, which is a less smooth solution, but is the fastest response your user can get on lower powered processors.

[edit] Reference

See another tips about good JavaScript pratices in:

[edit] Tools

[edit] See Also

This page was last modified on 16 April 2012, at 06:06.
222 page views in the last 30 days.

Was this page helpful?

Your feedback about this content is important. Let us know what you think.

 

Thank you!

We appreciate your feedback.

×