How do I get the timings and layouts of different frames generated while painting an HTML page which involves javascript manipulations and CSS3 animations by a webkit browser?
You can get the page layout by dumpRenderTree() provided by webkit, if that's what you wanted. Regarding the timing data, as far as I know you may need to build the webkit engine to enable it then you can get the timing data regarding rendering, network, Javascript, etc. - at least this is feasible for Android webkit.
Related
I have an application where I load different SVG files into an object and perform operations on them using JS. The code is all correct and works perfectly across all latest browsers, even IE11, with the single exception of Safari (including Safari on iOS and wkhtmltopdf).
When the application runs in Safari, performance on the SVG objects is abysmal. This includes initial page loading and changing the data attribute of the host <object>. Basic tasks like using setAttribute while looping over SVG elements can hang the application for minutes.
The application is entirely dependent on SVG interactivity so this is a major issue for me.
I'm pretty sure yet this is something related to the content of the SVG files. I've been playing around with simplifying the files to see if a particular type of SVG feature is to blame (patterns, styles, embedded images, <use> elements, etc) and while things do get faster as things like images are ripped out I haven't found any primary culprit yet and I can't really remove features without breaking the app anyway.
One odd thing I noticed is that changing from a "simple" SVG to a complex one is faster than the other way around. It seems like Safari has trouble cleaning up the complex object when it's not needed.
I've set up a demo page at the following link:
http://www.flooradvisor.com.au/shapes/backend/tests/webkit-svg-change-src.html
If anyone can help me understand why Safari hates my SVG files and what I can do about it that would be hugely appreciated.
What techniques can be implemented to improve the performance of a Jquery Mobile web application (no Phonegap, etc. has been used. Just a plain JQM mobile web application)? Things that we have already done include the following.
Minification of JS, CSS files.
Reduced or upto no images using font icons and image sprites.
Removed unwanted/unused CSS using mincss.
Used data-enhanced="true" wherever possible.
Used the latest JQM and JQuery libs (ofcourse =))
Page caching wherever possible.
Image scaling is not done. Different size images are sourced when required.
What else can be done to improve performance? What changes can we do in HTML, CSS and/or Javascript/Jquery/Jquery Mobile to further enhance the performance?
Regards.
Shreerang
A major item that I see missing from your list is reducing the number of elements on the page to the bare minimum. You probably have extra divs, spans, etc. on the page without even realizing it. Not only does the browser have to spend time rendering each element, if the style for a parent element is changed, the style for each child element must be recalculated as well!
A good way to look at your page to view nesting graphically is to check out the page using Firefox's 3D layout view: https://developer.mozilla.org/en-US/docs/Tools/3D_View and check to see if any elements can be removed or combined.
References:
Yahoo best practices: https://developer.yahoo.com/performance/rules.html#min_dom
Google minimizing browser reflow: https://developers.google.com/speed/articles/reflow
So, I need to implement mathjax in a web project, Did some research on who is already using it and found that,
https://math.stackexchange.com/ Uses mathjax to render mathematical equations and formulas. But when it gets rendered on the browser it is slow and a lag is present. How could this be removed or reduced more then what is happening right now.
MathJax is a very good renderer but isn't always the fastest. An alternative javascript math rendering library is jqmath That is noticably smaller and quicker than MathJax, but doesn't aim for all the same spacing refinements and the same coverage of latex math input.
The fastest rendering of course is just to use MathML in the page and require a browser that supports it. Current versions of Opera, Safari, Firefox and Chrome all support that to some extent. (For IE people need the free (not open source) MathPlayer plugin). My own html5mathml JavaScript sometimes helps to smooth the gaps between the different browser implementations.
we build a Sencha Touch application, which allows to search and display html documents. Nothing special, simple html document which user can scroll up and down.
Some of the documents are pretty big ~ 5mb of pure html. These documents slow down the application, sometimes it even crashes.
Do you have any ideas how to fix this?
5mb-size HTML file is very large, even for laptop browser. If you run it on mobile devices browsers than there's a very high probability that they will be crashed. (Nearly 100% for BlackBerry browsers.)
It's highly recommended that you should keep the size of each HTML file not exceed several hundred KBs (let's say 500KB). Then in each of your HTML files, provide "Read more" button for the users to navigate to the next chapter of your HTML content.
Please keep in mind that, the more complex the DOM is, the slower your Sencha Touch application will become, as it always has to completely manage your DOM structure.
I'm developing a HTML-based iPad application that makes heavy use of JavaScript for its UI. GUI is going to be magazine-like i.e. chopped into screens/views that the user then navigates between with touch events and webkit transitions. All of this runs locally on an iPad (via a native wrapper such as PhoneGap, etc.).
Lets say the application is going to have 50-100 of those screens - filled with standard web elements like text, images, tables and forms.
How to structure that for best performance? Which of the following 2 methods is preferable and why?
having only 3 immediate (current, previous, next) views/screens in DOM and then appending new ones (and deleting the old ones) into DOM as the user navigates forward/backward?
having the entire 50-100 HTML screens generated at start and then hiding (display:none) all of them but the above 3
So basically what works better memory/performance-wise? From one side continuous DOM operations might be costly (and worse make the transitions between app screens jerky) - and from the other side - don't know if having up to a 100 HTML screens pre-generated in a single document DOM won't make Mobile Safari choke to death. Of course even though those screens are in DOM, most of them are display:none most of the time - but is the mobile safari garbage collector that good? Has anyone tried this out?
BTW please note that this is not an image-memory problem/leak type question. I'm aware of that problem and will be handling it via small-dummy-image unloading trick no matter which way I go. This is only about HTML views - skeletons if you will.
If the content is all going to be downloaded to the device at the time of launch, and everything is locally cached, then definitely go with the first method, as it will have a significantly smaller memory footprint.
If the content is downloaded on the fly, however, I would go with a mix between 1 and 2... probably prefetching and rendering the next two or three slides in either direction, or maybe one in each direction and one for each link on the page.