Problems:

1. Try to collapse blending layers together: Transparent elements can be very expensive: Instead of a button with a transparent background on top of white, it’s faster to pre-composite in photoshop and create an opaque image.

(Below comes from 10 tips talk)

2. Get UI element from the server side will slow the application. Create UI element in javascript on Client side.

3. Don’t wait for data from sever side then display view. First display view, then update view with retrieved data.

4. Don’t forget to cache static data/frequently used dynamic data/frequently used DOM element/precompiled template

5. Some of the CSS statements are not hardware accelerated. Use CSS transition and hardware acceleration. for example translate3d(x,y,z)

5.1 Using translate3d too frequently will cause performance problem itself. i.  use up all of the available memory on the GPU; ii. a noticeable delay when upload the content of the HTML DOM element on the GPU for rendering.(Only happens when apply the translate3d style to a very large and very complex HTML DOM element) ( The more complex the HTML DOM, the larger the delay) iii. Nested DOM elements could cause problem because all of the child elements have to be uploaded to the GPU before the parent element can be rendered; iv.  If the DOM element is larger than the maximum texture size supported by the GPU (in either width or height), then you will encounter very poor performance and visual artifacts. v. different platforms have different levels of support for hardware acceleration, and performance can vary

6.Click event have 300 ms delay (Onclick) because it waits to see if user want to double tap. Use feature detection to decide if need double tap. Monitor touchstart (OnTouchStart) event rather than click event. Or use fastclick library.

7. Use lot of image/icon on a page. Composite all images in one image and use CSS sprite sheet.

8. Too many shadows and gradients.

9. Don’t modify DOM too frequently —— cause too many reflows. Prep your work off DOM (Use local variable to cache all the changes and apply it to DOM once). Also keep your DOM shallow and small (for example, keep only 3 slides in your DOM any time), which will lower the chance to reflow DOM and keep the reflow’s cost low.

10. Too many unnecessary libraries in index.html. Use lighter approach (micro-library; Few lines of code). For example, don’t use jQuery mobile to get page transition (instead use 10 lines of CSS), lead you stuck in an architecture you didn’t want.

(below comes from this post)

11. Have native feature functions before onDeviceReady. This is the method that’s called once phonegap has loaded and is ready. $(document).ready or whatever you’re used to, doesn’t really apply here – unless you’re only doing interface/hard-coded HTML stuff. If you’re interacting with iPhone features, like GeoLocation, you will need to do everything after onDeviceReady has been called.

12. Haven’t disable device-based feature not using in app. The accelerometer, geolocation features are by default turned on. If you’re not using them, I would turn them off, as your app will load faster (initialize) and run smoother.

 

1. In this slides, on page 40, the author suggests that “Don’t set style properties inside a loop” and “Don’t do what you do on the web”(need to figure out what are they?)

2. In this post. author suggests that “avoided heavy-weight libraries for mobile application development”.

The following comes from this talk.(slides)(mp3)(note)

• On page 10, the author suggests that “Don’t emulate native UI”. Because it’s hard to do and it may not get you a good result. What you should do (page 11) is to use document-oriented UI.
• On page 15, Bridges can have performance impact. Do these operations when not doing anything performance critical.
• On page 17, optimize the part where optimization actually counts. Don’t complicate other parts. Keep things simple.
• On page 19, Javascript also take more power for smartphone to execute.
• On page 20, move hotspot area(things like cryptography, security, interpreting values) (I guess it’s computation intensive area) into native code; Take a look at what Javascript library is doing.( For example, JQuery has lots of bits of pieces that were IE optimized and they were slowing down applications. Went straight down plain javascript will speed up the applications)
• On page 21, About Graphics. 60FPS is the standard and ideal UX, key is lean on the GPU, the way to do this on web app is to use CSS3 Animation and transitions. But on the other hand, as soon as you put a element in web code into css transitions, it will start using more memory. The memory limit for older version of ios is10 Mb;
• Still on page 21, Shadows and gradients slowing the CPU; Compositing & Overdraw  (How many times blending layers when composite different things).(Try to collapse blending layers together).  (Making transparent element opaque, because Opaque element is much faster than transparent elements.)
• 
• Q&A: Try to avoid dumb update when do a lot of animation. Don’t do animation in javascript.
• Flipboard start with web code and optimized by native code. Do simple thing first.

The following comes from this talk (related blog):

php here could be “asp, jsp etc..”. This will lead program go back to the server and fetch the page. The page is generated on the server side.-> slow

Get the page using ajax request. When the request come back, we insert it in the dom. We replace the body with what comes with the ajax request. As bad as the previous one. (Hijax your links, a common/default operation in jQuery Mobile) Bad performance.

Create UI and client side in javascript. Inject them in the dom and remove them as needed.

 

No need to invoke service for static data; Cached dynamic data(old data) as well…(when it make sense)

Don’t execute same query on the dom twice..

Use CSS transition; Use hardware acceleration

don’t let system wait for double touch.(300 ms delay)

Lot of http request..

reflows the dom make everything sluggish..Add element will relayout the dom…(don’t put modifying element operations in loops)

prep your work off the dom as much as you can; keep your dom shallow so that it will be lower chance to reflow your dom;

Don’t keep many invisible elements in the dom( you can just keep 3 slides in your dom instead of all of them)

Be careful before using library or framwork, need to examine whether the same effect could be achived by few lines of code or lighter library. (Don’t use jquery mobile just to get page transition)

 

test with right data set, with right devices, and with bad network/environment…

..

 

 

 

 

The following comes from HTML5 Rocks Tutorial

•  Offload tasks that would otherwise be calculated by the main CPU to the graphics processing unit (GPU) in your computer’s graphics adapter

 

 

Solution:

1. Two steps: i) identifying the modules that are the performance bottlenecks; ii) Tune HTML5 or Javascript (http://www.html5rocks.com/en/tutorials/speed/html5/); If the performance bottleneck occurs in a place that is not properly fixable by using JavaScript or HTML code, you can always dig into the native side.

Using performance intensive module to native side ( http://www.codefessions.com/2012/09/creating-native-user-experience-with.html)

Observation:  the Native and JavaScript can send up to more than 20000 string messages per second back and forth. So, any performance intensive module can be moved to the native side in an efficient way. It is just the matter of properly designing the communication protocol and calls. (developing your code in a way that can use string messages efficiently) http://www.codefessions.com/2012/10/improving-performance-of-html5-based.html

(From http://www.whitneyland.com/2013/08/accelerated-hybrid-mobile-apps-the-sweet-spot.html)

Why people say phonegap is slow:

1. JavaScript is not as fast as native code

2. Apple limits these solutions by removing many optimizations from UIWebView, the component that enables HTML5 rendering in iOS hybrid apps. The result is that CPU bound JavaScript in a hybrid app can be up to 300% slower compared to JavaScript in mobile Safari.

3. Different platforms have their own quirks and foibles; what works well on iOS isn’t always best practice on Android. A skilled developer who understands the platform they’re working with can improve performance, stability and usability by applying best practices to squeeze the maximum amount of processing power from the device for smooth performance and a frustration free experience.

4. Bugs happen and if it turns out to be in the code generated by the hybrid app platform you may find it difficult if not impossible to fix. With a natively coded application the developer has a complete understanding of how the application works and full control over the code.

5. Programmers also have to learn the details of building on each platform, and even though the code base is the same, a different configuration and build for each operating system is still required.

6. Execution time increases due to an architecture that requires to invoke methods using at least one callback and waiting for its response.