I'm troubleshooting a performance regression in a large webapp. I recently made some changes to remove an IFRAME and put the contents directly into the original DOM, to make performance better. Indeed, initial load time is better, but I've found a strange problem.
It seems that various layout (animation and scrolling) changes are MUCH slower with this iframe removal. I've narrowed it down to know it's not javascript.
I've removed all javascript that was running on timers and events.
I can see the slow performance when simply setting a classname on an element which has a 1 second CSS transition, which changes its style.top and style.left. (It's already absolutely positioned). This element animates to the new location very slowly .. seems like about 5-10 FPS, whereas with the IFRAME it was 40+ FPS.
So -- I'm wondering if there is some way to measure actual browser layout performance. I see this problem across the board on Safari, IE, Firefox and Chrome -- so any of these would be fine to use (though I prefer Firefox because the problem seems to be most defined there).
A good place to start - Speed Tracer and Page Speed. They will show you a lot of useful information about how your layout affects performance and what you can do to improve it. Although Speed Tracer is a Chrome extension its data will also reflect performance in other browsers too.
Here's a really interesting test for the browser itself:
Maze Solver: CSS3 Layout Performance Test
Performance on the web is multi-dimensional. In this test we focus on the browser layout engine to exercise the browser's handling of CSS 2.1 and CSS 3 layout constructs. These constructs are used to style HTML, and the layout engine is an important component of overall web browser performance.
Again, this test is for the browser itself, not your code, which, if I understand correctly, is what you're looking for.
Related
I develop a small application to test CSS3 and translate3d. The idea is to render several DIVs moving randomly on the screen. It's kind of particle system, I know I could probably use WebGL or Canvas to have better performances but I also want it to work smoothly on mobile browsers hence I thought that DOM manipulation would be better for performances.
You will find the result after a couple of hours at this url
I'd like to reach the best performance possible to increase the number of DIVs.
But here is my problem, I have a "rendering issue" that I spotted when I used TimeLine on Chrome or Safari. From time to time the whole page is rendered generating a small lag perceptible on Safari iPhone or Chrome Android+iPhone.
So if one of you one is up for the challenge don't hesitate I tried many things but I didn't figure out how to avoid this expensive redraw.
BTW, if one of you have extra ideas to optimize this snippets don't hesitate to reply.
Thanks
---------- UPDATE 1 ----------
Based on Ariya advices I updated by code (url) and added another test using only top/left.
Based on the FPS counter provided by Chrome I can see that the fps is more stable using top/left properties with almost the same framerate.
Do you have any idea if I could optimize the CSS3 version to have even better performances? I though that css3 with GPU Acceleration would be faster I probably did something wrong.
---------- UPDATE 2 ----------
I updated my code to use requestAnimFrame and only fire it when I need to redraw.
And I found what is killing the perf gray gradient background that I defined in the css was redraw often and killing the performance.
However top/left seems still better than CSS transition :( from a pure performance point of view.
When looking at the Timeline profile in Google Chrome's Developer Tools, it's evident that there is a lot of style recalculation. This is to be blamed at this particular line:
lastSheet.insertRule('#-webkit-keyframes '+keyframeName+' { ....
In other words, continuously changing the style sheet is expensive. Since the element animation in this example is about moving them around, rather than using keyframe-based animation I would recommend simplifying to simple transition.
For our website, we are developing a "component" that would display images in a similar fashion to Time Machine on Mac OS X. So it will be many images on top of each other, positioned slightly differently and with a smooth animation as you scroll forward and backward.
We have a spike implementation with CSS3 animations but it's not very smooth in Firefox and IE9 is not supported at all (though we may live with it if the other options are even worse).
We are considering implementation in SVG or Canvas but don't have much experience with it so I thought we'd ask first. So:
Requirements:
It must be fast. The animation must be smooth and that is a hard requirement.
It should be supported in as many browsers as possible.
Required browsers are Chrome 20+, Firefox 14+ and IE10+.
We would very much like to have support for IE9 too but can live without it if absolutely necessary.
Opera is nice to have but not necessary.
Options and our current experience / opinion on them:
CSS3 - seems like the "appropriate" technology for the task but unfortunately the implementation doesn't work so well. Maybe we have inefficiencies in our prototype code but the support seems quite different between different browsers at the moment.
SVG - at least it's vector graphics / DOM elements but we don't have any experience with it.
Canvas - we hope that it should perform well as it is used even for games but we can't quite imagine how would all the pixel redrawing work. Maybe we should use some libraries like processingjs?
Flash or other plugins - I happen to know Flash quite well and I know that the Time Machine-like effect would be quite an easy task there but we'd rather stay away from plugins at the moment.
Thanks for advice.
If the size of the component does not have to be very large, but can be limited to say around 800x600 pixels, then it sounds like Canvas should be up to the job.
If you only draw (scaled) bitmaps to the Canvas then performance is very good in my experience, even on iPad2. Performance only really starts to suffer at higher resolutions (1920x1080 and above), so if you use it for a fullscreen feature you need to watch out! Also, fancy features such as drop shadow etc. can slow down performance considerably as well.
Canvas has very few quirks between browsers, so it will almost certainly be less painful than using CSS3 or SVG in terms of getting it to work as expected across a wide range of browsers.
I would recommend whipping together a quick and dirty prototype with Canvas to see if it will meet your first requirement regarding performance.
If you decide to go with Canvas, I would definitely recommend using a library. Since you know Flash quite well you might want to take a look at EaselJS. It has a display list inspired by Flash, and the performance cost of using it is negligible in most cases. You also get basic events for interactivity. Also, if you go with EaselJS, it would be quite simple to port the code to Flash later if you decide to.
Are you looking for something like this? It uses SMIL animation so you'd have to integrate something like fakesmile to get IE support.
I have a design I'm creating in CSS, and it has started to sort of, er, lazy scroll. By that I mean the scrollbar lags a bit when you are scrolling. What are common causes of this so that I can debug it from my site?
EDIT:
The document has very little content (not even a paragraph), so not much at all. No flash, two images.
EDIT:
I feel so stupid. Improperly formatted background: property was causing the issue. Thanks nonetheless, everyone.
It's likely to be due to heavy processing requirements via css.
(CSS does affect scrolling in every browser) I have seen this scenario many times (the worst case is with SVG). It usually hits browsers like Chrome hard because of it's AA.
There was a great website that detailed the heaviest to the safest properties to use in regards to CSS effects, sorry I don't have the link. Though from my experience I would say to consider:
Gradients: The more you feature or the larger the area they cover the more exponential the rendering calculations. Abusing stops and additional colors also adds to the mayhem.
Border-Radius: Is usually clipping off its internal content whatever it may be. I've noticed differences when excluded.
Opacity can be the main issue if coupled with other css effects. In certain scenarios I've found great improvements when removing opacity or reducing it's usage. As it's not just transparency it's driving it's also for some browsers anti-aliasing text.
Images: The way images can affect scrolling should be obvious, though I've discovered re-sizing imaged from it's native resolution can become a more noticeable factor.
Use of properties such as background-size:; draws huge power in certain situations, a workaround could be to scrap the div, replace with < img > and overlay with a blank div
containing text/ content.
Animations transitions & translations are obvious power eaters if abused, especially animation that loops continuously or re-sizes to the browser via percentages.
Bare in mind someone on a low spec celeron PC will have a terrible experience on a site that lags on your reasonably/ high powered PC/ mac
Layout and rendering of HTML content can take some time if the HTML is complex enough. I couldn't find a set best practices for how to code HTML in order to help the layout engine (specially in IE) so that page redraws are faster. Does such a set of best practices exist?
My current specific problem is that my tabular data (in a table element) that causes drawing the page too slow, and making DOM updates (hover effects) and animations very sluggish. I'm sure it's not JavaScript performance. I've checked the page using dynaTrace AJAX. The CPU becomes too busy when I hover my mouse over elements, but there's no JS running. And the hover is realized by adding/removing a class to TR elements. I've also tried YSlow in Firefox, it doesn't show any particular issue. It's not network-related either. (Firefox lays out the page faster, but it's not because of its JS engine being faster)
Is there a tool to profile drawing and layout in IE, so that I can find out where the problem is coming from? And what can cause the drawing to be so slow, so that I can avoid them in HTML code?
Internet Explorer is known to be slow with rendering large HTML tables.
Refer to this nice article on MSDN: Building High Performance HTML Pages and specifically to the section about tables:
Set the table-layout CSS attribute to fixed on the table.
Explicitly define col objects for each column.
Set the WIDTH attribute on each col.
Then there is also a nice blog post on the ieblog about table rendering: Table Rendering.
It comes down to this: Try to make the content within the tables less complex, i.e. set fixed width and don't have too much dynamic rendering action going on. IE first loads the content and then has to calculate the correct width for the contents == slow.
I am developing a jQtouch app and each request done via ajax creates a new div in the document for the loaded content. Only a single div is shown at any one time.
How many div's can I have before the app starts getting unresponsive and slow?
Anyone have any ideas on this?
EDIT: Its an iPad app running on Safari, and it would be less than 1000 div's with very basic content
I've had tens of thousands, maybe even a hundred thousand divs, on screen at once.
Performance is either fine, or bad, depending on:
Parsed from HTML or generated Dynamically in JavaScript?
Parsed from HTML means you have a LARGE html source, and this can make browsers hang. Generated in JS is surprisingly fast, even on Internet Explorer, which is the slowest of all browsers for JS.
To be honest, if you really need an absolute answer to this question, then you might want to reconsider your design.
No answer given here will be right, as it depends upon many factors that are specific to your application. E.g. heavy vs. little CSS use, size of the divs, amount of actual graphics rendering required per div, target browser/platform, number of DOM event listeners etc..
Just because you can doesn't mean that you should! :-)
As others have said, there's really no answer.
However, in this talk about the Google Maps API version 3, the speaker brings up the number ten thousand several times, as a basic threshold for browser unhappiness.
http://code.google.com/apis/maps/documentation/javascript/
Without defining a particular environment, it's not possible to answer your question.
And even then, anything anyone tells you is just a guess. You need to do your own testing on real-world configurations with different browsers and hardware. You'll also need to establish some performance benchmarks to decide what "too slow" even means.
I've been able to add several thousand divs without a problem. Depends on what you'll be doing afterwards, of course, and the memory on the client machine. Everyone else is right about that.
As Harpo said, 10K is probably a good ceiling. At one time, I noticed speed problems starting at about 4K divs, but hardware has improved since then.
And, as Neil N said, adding the divs via scripting is better than having a huge HTML source.
And, to answer Harpo's comment, one way to "break it up" so that JS doesn't lock the page and produce a "page is running slowly" error is to call a timer at the end of each "add a div" routine, and the timer in turn calls your "add a div" function again.
Now, MY question is: is it possible to "paint" so that you don't need to add thousands of divs? This can be done with the canvas tag with some browsers, but I don't think it's possible with VML (the excanvas project) on IE. Or is it? I think VML "paints" by adding new elements to the DOM, at which point you may as well use DIVs, unless it's a simple shape.
Is it possible to alter the source of an image via scripting? (the image in the DOM, of course -- not the original image on the server.)