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.
Related
I have an application that displays a page with 5-10000 rows in a table element and has a drop down menu that switches to other views with a similar structure. Currently I do an async request when switching between views (I also clear/remove the current view from the document) and load the appropriate list each time; however, I was thinking of
1) loading all views in the background before they are requested for viewing so they load instantly on click.
and
2) Just hiding a particular set of rows rather than removing it so if the client navigates back it will be instant as well.
This would mean that potentially 10s of thousands of html elements would be loaded into the current document; is this a problem? What if it was more than 10's of thousands?
Loading 10000+ HTML elements onto your page is not a very smart idea. If the user's computer is of normal to fast speed, the user may experience slight lag, and if the user's computer is slow, it may even cause a system crash (depending on the amount of RAM on the computer).
A technique you could explore is to lazyload the HTML elements - this means that when the user scrolls down to a particular portion of the page, then the elements are loaded via AJAX. (also known as "infinite scrolling").
This means that the browser's rendering engine does not have to render so many elements in one go, and that saves memory, and increases speed.
It depends on the HTML elements, but I would say as a rule of thumb, don't load upfront.
When I say it depends on the elements, I mean take a look at facebook for example. They load maybe 10 or 20 items into the feed, and then add more as you scroll, because each item is so rich in content (photos, videos, etc).
However on the flipside of that, think about how much info is in each row, if it's say, less than 500 bytes, 500 x 10000 = 5MB, which isn't an awful load for a web request, and if you can cache intelligently, maybe it will be a lot less than that.
The bottom line is, don't assume that the number of HTML elements matters so much, think about the amount of data that it amounts to. My advice, cross that bridge when you get there. Monitor your request times, if they are too long, come up with an AJAX page loader, which shouldn't be too hard.
The size of your html document would be conciderable...
I once got a page with 5000~10000 items (table rows) and the browser (IE) was rendering way too long (downloading the page, parsing and rendering it).
The best solution seems to me to set up a WebService with a LazyLoading system.
So IMHO yes, the number of element in a HTML document should be monitored.
Yes of course! The number of element in a HTML document can be monitored.! Use FireBug in Firefox!
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.
I have a page using JQuery and I've implemented infinite scrolling on a div. There is a text area on the page. I've noticed that as more rows get added to a table in the scrollable div performance of the page gets worse. You can really tell when the page size is large and you try to type anything in the text area because there is a large lag between the time text is typed into the textarea and the time that you actually see the text appear. This only happens in IE8. I haven't tried other IE versions. It doesn't happen in Firefox. It is really fast in Firefox.
I've used a tool to check what IE was doing and it is spending most of the time doing generic rendering of the page for each key stroke even though nothing new is being added to the page.
Why is the page rendering so often and slowly in IE8 and is there a way to improve this?
I believe that the tables are the cause of your performance issues. I had similar problems when using js to dynamically add rows to a table containing form elements.
See this Microsoft Article for tips on how to improve performance, specifically when using 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.
e.g.:
table
{
table-layout:fixed;
}
Avoid nesting tables within tables etc.
W3Schools highlights the advantages and disadvantages to using different table layout algorithms.
FireFox appears to handle the rendering of tables more efficiently than IE but using these techniques appears to help most browsers.
Hope this helps!
A similar problem can occur with lag on text areas in IE8 for very large pages. It does seem to be a problem with IE8 rendering the page on every key press.
One solution is to use an iframe with contentEditable set to true instead of a textarea. This works without any noticeable lag at all on the same page. I suspect this is because IE8 is only rendering the contents of the iframe on each keypress and not the parent document. It may also work with a textarea inside an iframe but I haven't tried this.
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.)
Is it possible to use CSS to work like frames?
What I mean is, when we use frames (left, right for example), clicking on left will refresh only the right section using the 'target' attribute.
Is it possible to create this effect with CSS?
Thanks.
Using frames is usually a bad idea
To answer your question, no, CSS cannot be used to work like frames. CSS is used to changing the style of HTML and as such, cannot actually change the content of a page. It can be used to hide content, but I don't think that is what you require.
However, I feel in this case you may be asking the wrong question. As frames are usually the wrong approach.
When starting out in web design, frames seem like a great idea. You can seperate your navigation from your content, your site will load quicker because the navigation is not loaded every time and the menu is always visible, even when the page is loading.
But, actually, frames are incredibly bad for your usability.
Your users cannot bookmark individual pages
Printing is broken
Standard features in a browser like open in new tab often breaks
Users cannot copy/paste the web address for a specific page for sending to a friend
Frames do have their uses (e.g. Google image search), but for standard navigation menus they are not recommended. Try creating a page in a dynamic server language such as PHP or ASP.NET.
These languages have ways of creating standard elements such as your navigation menu without the use of frames.
No, this has nothing to do with CSS. CSS is for styling elements only. What you are looking for is an IFRAME. And IFRAME can be given a name
<iframe name="my_iframe" src="xyz.htm"></ifram>
and then be targeted in a link.
I've got a design that relies on framed content using CSS. You can do this by using overflow:auto, however it won't do what you want, i.e. loading certain portions of a page. To do this you'd need to use some AJAX library such as jQuery to load the content area dynamically. This is quite dangerous though as your URL may not relate to the current content of the page.
You could probably do something with the overflow part of CSS.
If you set up a div with overflow:auto with a fixed width and height with alot of content you will get scrollbars. Potentially you could use anchors to get content to move to be viewed within the div.
This means that all your content is in one page and it is just moved around with the anchors. You could do a similar thing using a jquery tabs plugin too.
I have never tried this and it might need javascript to get it to work fully.