How many divs can you have on a webpage at one time? And what would be controlling that limit?
There's nothing limiting the number of divs on a website (other than the memory on your machine).
There isn't a hard limit in any modern browser. I've literally iterated and printed thousands of divs on pages before. Your real limiting factors are going to be how big you want your page to be and of course, eventually your page will take a very long time to load.
I just ran a test case where I inserted 2,097,152 divs in a page and though it was slow to respond, it did eventually come up without choking either IE or Chrome.
If you need more information, or perhaps help figuring out an approach that wouldn't take so many divs as to require this question, just let us know.
Related
I am in the process of building a site with a large amoutn of divs, perhaps 300-1,000. Each are small, 100x100, and when the user clicks on each div a small modal pops up w/ basic info about each div, maybe 2-3 paragraphs and some images; all this works great. However, I fear as the divs increase in quantity, this amount of images/texts that are loaded will slow down the site to a crawl, resulting in a terrible ux; it's also aesthetically dispeasing to me (and I'm sure to other coders) to have so much code on a single page. So the question is thus: what is the best way to make modals that load quickly, but don't slow down the site, or are there alternatives to them?
I thought about imbedding the modal content (text,images) inside CSS, and perhaps makig it between 2-5 css files?
I thought about pop-ups, but those are problematic, as some browsers won't respond to the specific size dimensions of a pop-up, (IE), and some block pop-ups all together.
Has anyone else dealt w/ this or has an interesting solution?
I appreciate everyones help.
I come from no server-side programming knowledge, so I have an issue. Here is the situation:
I have a large group of pictures, about 1000, that are related to each other in some way. I have written a function in C that creates an index table of relation between each picture. It is very long and complicated, no need to put it here, all you need to know: If they aren't related whatsoever, the index is 0, if they are very close, it goes up to 99, with 100 being the same picture. I can output the table into any sort of file that would be useful for retrieval online.
Now, I want to use this idea for a website. I have a domain and a file system, but I haven't messed with any server scripts or anything, because I don't know where to start. I have an html/css setup with several divs set up in decreasing size, and my goal is that when a certain picture is selected, it will be loaded by the biggest div, and then subsequently load related images in descending order into the smaller divs. I am not sure how to do this, both in terms of the 'relation' attribute and in terms of retrieving said attribute. Thanks for your time, I know this is very long question so sorry.
edit: to avoid confusion, I only have a few total divs, not the thousand all at once haha
I have been tasked with optimizing a marketing landing page for speed. It already does really well, but the problem is its very graphic heavy.
The entire thing I would guestimate is 30+ pages long all on one page (It must be like this, and everything must be images due to conversion reasons).
Here's what I've done so far but I'm not sure if there's something else I'm missing
I re-compressed over a 140 jpg's on the page to slightly smaller sizes
I played around with sprites but most of the images are all large (like entire testimonial boxes that are 600px wide). The sprite images ended up being like 2mb. That page actually took longer to load for some reason (by almost 2s) so I took them off
The MOST important thing is that everything immediately at the top loads as fast as humanly possible and before anything else so that the sale isn't lost by someone starting at a bunch of images loading out of order. I used some preaching images with this method: http://perishablepress.com/press/2009/01/18/css-image-caching/ - It did seem to work quite well on the smaller images, but when I add the background (which is very graphic intensive) everything seems to slow down at once, like its trying to do a certain number (5?) of images at a time. Ideally I'd love to group the first 4 smaller images being pre-cached, and then follow it up with focusing all bandwidth on the background, then the rest of the entire page in standard order..
Google Page Speed score is 90/100. the only thing its concerned about is unused styles but that I'm not really concerned about because its about 2kb total... the overhead from the 7mb of images is way more important.
I have the option to use a CDN for the images but I'm not sure how I'd go about doing this or if it would actually help?
I feel I've done all I can but then again I could totally be missing something...
A CDN would definitely help. And with 140 pictures, I hope it
contains more than just server. Just link directly to the IP of
the servers, to avoid unnecessary DNS lookup.
Minimize HTTP requests. You mention that you've been experimenting
with sprites. I still believe sprites to be the way to go, but you
might not want to create just one, huge image. If you have 140
images, you should probably have about 10 sprites.
Make sure that you have set headers to make the client cache all
content. Remember ETags.
Gzip/compress content for browsers that allow it.
If the source code is lengthy, make sure to flush the buffer early.
Consider lazily loading images below the fold? There are a number of javascript plugins to accomplish this
scrolling pagination + combining images as sprites on a per-page basis.
Is there any way to do this without bogging down a computer?
I don't know much of the innerworkings of computers and browsers, so I don't know what about a bunch of images on a page takes up so much cpu. My first thought was to hide the images that aren't visible on the page anyway. The ones that have been scrolled past or yet to be scrolled to.
I tried a sample jsfiddle with randomly colored divs instead of pictures, but just scrolling up and down through that makes my computer sound like it's taking off.
What is it about all the pictures that takes up cpu? Can it be avoided?
The question is generally not about the amount of bandwith it might save. It is more about lowering the number of HTTP requests needed to render a webpage.
See this
What takes time, when doing lots of requests to get small contents (like images, icons, and the like) is the multiple round-trips to the server : you end up spending time waiting for the request to go, and the server to respond, instead of using this time to download data.
Less http requests = faster loading overall
If we can minimize the number of requests, we minimize the number of trips to the server, and use our hight-speed connection better (we download a bigger file, instead of waiting for many smaller ones).
That's why CSS sprites are used.
For more informations, you can have a look at, for instance : CSS Sprites: Image Slicing’s Kiss of Death
Other than this you can also use lazy load
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.)