Hi I was wondering if there is a limit to the number of divs that are allowed on a web page?
For example will Internet Explorer start to choke when it has to render a webpage with a thousand divs?
I know this is an old post, but I recently did a test that is directly related to this topic and I wanted to share my results.
I created a simple php script that spits out x number of 5px by 5px inline-block divs to test browser stability and page scroll-ability.
At 1000 divs on the page IE9, Firefox, and Chrome have no problem whatsoever and don't even seem to hiccup when scrolling.
At 10,000 divs IE9 and Chrome are able to scroll with a barely-noticeable delay, still within the 'acceptable' range in my book, however Firefox begins to lag more noticeably, to the point where you feel the scroll bar is jumping into position a half-second later than it should.
Interestingly, the performance difference between 10,000 divs and 100,000 is not as drastic as you'd imagine. IE9 and Chrome perform with only a barely perceptible delay in scrolling (with Chrome being the slightly smoother of the two), and Firefox has a delay that is very noticeable and would probably be considered annoying, but still functions reasonably well (i.e. it doesn't crash).
Now at 500,000 divs on the page it finally started to get interesting. IE9 Crashed and tried to restart itself (on the same page, of course) and crashed again, at which point I shut it down properly, restarted it, and tried one more time to make sure the same result would happen again. It did.
Chrome remained stable, but it became nearly impossible to scroll the page due to the extreme delay.
The big surprise was Firefox, the browser that was chunky at 100,000 divs is just about the same at 500,00 divs ... scrolling is not smooth, but it is way, way better than Chrome.
Amazingly, the results were pretty much the same for 1,000,000 divs on a page! Firefox handled them without crashing and remained scrollable though 'chunky'. IE9 crashed. And Chrome was able to load the page but became so slow that it was virtually unusable.
I know this isn't exactly a scientific study, but I figured it might be interesting to someone else besides myself.
Tests were performed on a Dell workstation with Dual-Xeon processors and 4 gigs of ram, running Windows 7.
There are two things to consider. Memory is one, where DOM nodes take up a huge amount of space. The other is CPU time needed to re-render all of these nodes when something changes. The threshold of smooth rendering depends on the engine used. In my experience, IE falls far behind, starting to choke after several hundred. Firefox can take several thousand, and it's about the same (and a little better) for WebKit browsers like Chrome.
Related
I have an app written with Konva.js, and it works really smoothly on both my 13-year-old PC and my wife's iPhone XR - it's just perfect. But whenever I run it on my Xiaomi Redmi 9 Pro and also my older one, Xiaomi Redmi Note 4X in many different browsers including Chrome, Opera and Firefox, it is really slow. I have animations using Konva.Tween and also some draggable nodes, and both of them work unbelievably slowly, FPS seems to be close to zero.
The strangest part is, I tried moving draggable nodes to a separate layer right before the dragging starts, and it doesn't speed up dragging at all, not one bit, at least visually, I didn't measure the actual FPS. So to me it seems like I am facing a limitation of my phone's performance here or there's something else which I do not see.
What is it that might cause the issue?
First, you should run the performance profile on your phone and take a look at what exactly is slow. Konva code execution? Native 2d canvas rendering? Browser layout work?
Also try to experiment with Konva.pixelRatio property https://konvajs.org/docs/performance/All_Performance_Tips.html.
Konva.pixelRatio = 1;
The image may be blurry on HPDI device, but probably it will be good enough. Probably default pixel ratio is too high. You can try different values like 1 or 1.5.
I have a situation where the CPU used by firefox jumps up to about 50% and does not decrease when I go to my app's tab. The app is idle, I am not clicking on anything, and no requests are being made. Yet the CPU does not drop.
I used Firebug to profile what was going on, but it returned that there was no javascript calls.
So then I used the most recent Performance profiler in Firefox 40. Running the profiler for about 5 seconds then stopping showed that the gecko engine was sending lots of calls to "Recalculate Style", specifically the hint given was that it is related to CSS Animations. See screenshot:
I need to find out what is causing this because I believe it is inherently slowing my app down. However, I am not sure what to do next in order to track down the issue.
Thanks
Problem turned out to be an animation that was off screen but Firefox was still burning CPU calculating the keyframes etc.
I have a strange problem on a small page I made.
When the content extends the height of the browser and I scroll down fast, the pixelated box appears for a split of a second and then goes away.
Why is this happening and how can I fix this?
Seems to be a chrome issue. I'm noticing this on a lot of websites since I moved from Firefox to Chrome.
This is just Chrome's rendering engine being crap. For the supposed "fastest browser", it fails to render part of the page when scrolling consistently often.
That said, there are some factors involved in when it happens. Generally, it can occur when there's a lot of layout recalculation. This may happen if you have a large table with images loading in, as each image's load causes the table to recalculate. Additionally, JavaScript can often cause recalculation in the layout. And it all depends on how powerful your computer is and how busy it is with other tasks.
I am currently developing a web application focusing primarily on Chrome 24.01312.57 and IE10. In the former browser, I am experiencing a large amount of lag. However, the latter experiences little to no lag, which is quite opposite to what everyone claims.
To show you the difference, I am recording the screens of my netbook using an iPhone while scrolling down The Chrome Webstore - something Google itself created.
Testing Equipment
2 year old Gateway Netbook -Single Core Intel Atom - 1GB RAM - Win7
iPhone camera (not that great recording solution, but it is quite easy to spot the difference)
Website: https://chrome.google.com/webstore/category/home (I scrolled down quite a bit for both the browsers before starting the test for those worried of AJAX loaded content slowing down the rendering)
Results
Google Chrome 24 (No extensions) scrolling down the Webstore:
http://www.youtube.com/watch?v=njkRqiNJPIY
Internet Explorer (No addons) 10 on the same page:http://www.youtube.com/watch?v=B_E_9OzPers
Note: Look at the mouse cursor and the scroll thumb - on IE10, the mouse is always on the the thumb whereas Chrome, it is all over the place indicating a high latency between mouse movement and the actual rendering.
Bottom Line:
Before I conclude, do realize that these lags on Google Chrome are increasingly magnified as the website becomes more complex and/or the specs go lower. However, IE10 is pushing the FPS quite high even in these conditions. I also did some analysis of the Chrome timeline. In reveals that the FPS drops as you zoom out to the point where rendering takes up to ~900ms per frame (on the Google Webstore) while IE10 is still fluid smooth (and better yet it retains that smoothness on an atom netbook)
As web developers, is there some CSS property/ies that is causing Chrome to render the pages with lag?
Why is Internet Explorer rendering so quickly?
What can be some steps to make Chrome render as quickly as IE10?
PS: Bug Report: http://code.google.com/p/chromium/issues/detail?id=163092 but no recent developments on this currently.
Chrome struggles with painting, especially at high resolutions such as 2560x1440 and above. Many websites such as the Chrome Web Store, Facebook, etc. exhibit significant scroll lag on it. IE10 maintains 120 fps on my monitor while scrolling on these sites.
I just had and fixed a similar issue.
Apparently Chrome isn't too smart about their recalculation of styles, besides that being terribly slow, so I focused on preventing it from recalculating anything.
I added the 'scrolled' class whenever the scroll event was triggered, but if it was already there, Chrome kept recalculating the new styles anyway. When I modified it to be like:
if (!body.hasClass('scrolled')) { body.addClass('scrolled'); }
Chrome suddenly experienced a significant speedup (still no IE or FF, but much better than before)
It's the video card on the Netbook! You will experience similar effect on almost everithing that moves on your screen.
I have a Netbook...
The web you are testing crashed Chrome browser until not long ago...
Please look at this page in IE and Chrome/Firefox: http://goo.gl/kR2Cv
In Chrome/Firefox it loads quickly and works fine, but in Internet Explorer it loads slow and is very laggy. In the page I use HTML5 and jquery/stepcarousel with alot of images. The whole site is just one html-page.
What I dont understand is why it works so good in Chrome/Firefox but not in Internet Explorer? Someone who can point that out to me and maybe help me with a solution?
Thanks.
Internet Explorer had a notoriously atrocious engine before version 9. In addition to lagging well behind in support for modern standards, it was very slow as well. Versions 9 and above, however, have improved significantly, and as a result, your website runs similarly smoothly in IE9, Firefox and Chrome. However, in IE8, it runs extremely slowly as you say.
If you want to support IE8, perhaps you can fall back on a less effects-heavy design just for those users, to keep performance optimal.
Your site is way too heavy. It's nearing 3mb, takes 12s to load on Chrome (10mbps connection). You should avoid downloading all those background pictures until they are needed, and optimize the hell out of them (use ImageOptim, PunyPNG or similar, you'll have to sacrifice a little quality for JPEGs). Aim for <600kb on the home page.
Older IE versions have lower parallel download limits than modern browsers, and are probably choking on the amount of images loaded.
It's a lot of HTML for IE8 to be moving around all at the same time. That's it's a table layout probably doesn't help. Tables tend to trigger a lot more reflow calculation.
Lots of good advice on the subject here:
http://www.stubbornella.org/content/2009/03/27/reflows-repaints-css-performance-making-your-javascript-slow/
With my slow connection FF loaded the page ten times faster than IE9. I think you have a problem with the fileformat. The code below is a snippet from your code:
kläder för dam och barn, från idé
Make sure you save the file in DOS/Windows or ANSI-mode.