This question has more to do with the way a browser handles objects created/rendered by HTML and CSS, rather than just a scripting question.If I have a div that is 100 pixels by 100 pixels and I want it to have a nice translucent blue background but I don't want to use CSS to set the background color to RGBA (and then just adjust alpha) due to browser compatibility issues, so instead I make a .png file that is a solid translucent blue and set the background image of the div to that png file and then tile it....
I can tile a hundred 1px image squares.
or
I can tile four 25px image squares.
Both will create the same effect except the 1px image square will load MUCH quicker than the 25px image square.... but I'm wondering if having 100 image squares on the screen will lag the browser more than only having 4 images on the screen that are of larger images? The browser itself, does it create a new reference for each image tile and then have to keep track of them all and update the position of them all?
It seems like putting 100,000 1px by 1px images on a webscreen would lag more than putting one 100,000px by 100,000px image on the screen? Especially if the user is scrolling up or down. Right?
The task of repeating the image n amount of times is the up to the user's machine to execute. It's dependent on the processing power of the average user's machine.
If you consider that on average you'll get 2-3GHz of processing power out of the average user's computer and compare that with an average download rate of 10 Megabits/sec, I would say that the bottleneck is download speeds. These days the lag with network speeds is almost negligible, so the difference would be so small that its not really worth worrying about, but nevertheless, the network lag of downloading a larger image would probably be worse than the lag of the processor to tile the image for the browser.
Whether you tile a larger image 20 times or a smaller image 200 times, the browser would still use the same execution loop to perform the tiling of an image, just more iterations in the latter, so I think the processor would be much more efficient than the network.
Also, I would say if you can achieve the same effect with smaller images, its more thoughtful and polite to your users to use the absolute minimum bandwidth possible with these insane ISP prices and bandwidth caps.
Related
I'm wondering what the best practice is for loading high-resolution images on a webpage. Currently I'm loading a bunch of images locally and the website is running super slowly. Here's an example:
https://shmoss.github.io/Gibbs-Lab/research.html
And here's how I'm actually loading the image:
<!-- Card image -->
<div class="view overlay">
<img class="card-img-top" src="img/Forest-Conservation-and-Biodiversity.png" alt="Card image cap">
<a>
<div class="mask rgba-white-slight"></div>
</a>
</div>
I read that images should be loaded locally, rather than hosted somewhere like on Box, Google, etc. What can I try next?
This is a bit of a "highly opinionated question", since many people will have different answers based on when they last looked at "standards", but here's some fairly recent guidance to work from. It's guidance, not rules, so feel free to make some judgement calls with it.
What is the best image size for websites?
The size of your images varies depending on where you want them on your website. The optimal file size for images on a website is no more than 200 KB, and for full-screen background images, between 1500 pixels to 2500 pixels wide, and for most other images a max-width of 800 pixels. Keeping images between these perimeters will ensure they load properly on computers and mobile screens.
https://northwestmediacollective.com/blog/best-image-size-for-websites/
There's other guidelines out there, this is just the first one I found that seems reasonable.
To display larger images, you should make the small "thumbnail" images clickable, which would then open either another tab to view the image, navigate to the image, or display a modal/div/something to display the image over top of your page. This allows people to select which images to see and download. This frees up bandwidth for just the one pic they are looking at, instead of "all of everything at once".
In your case, you aren't displaying a gallery, just header images to some text, so your images don't need to be anywhere near as big. The resolution you are displaying at is far lower than the image, so most of that detail is completely lost. There's really no point in having 3.5 mb, 3600 x 2400 px images when you are displaying them at 243 x 162 px. Resizing the page, it grows to 351 x 234 px, which is still wasting resolution, meaning you can greatly reduce your resolution and still get the same look on the client's machine.
A JPG file loses data, anyway, so if you want to keep detail at a lower resolution, you can try using a PNG. This is also a bit of a "highly opinionated" subject, so I'll just leave the link below and let you decide.
What is the difference between JPEG and PNG files?
Despite their similarities and widespread use, there are many differences between JPEG and PNG files. Because of their different compression processes, JPEGs contain less data than PNGs — and therefore, are usually smaller in size. Unlike JPEGs, PNGs support transparent backgrounds, making them preferred for graphic design.
https://www.adobe.com/creativecloud/file-types/image/comparison/jpeg-vs-png.html
To add some context to resolution and file size changes, if you reduce the resolution by 2, you are reducing the file size to approximately 1/4 of the original size. A 3.5 mb file becomes ~875 kb. Do it again and it's ~220 kb. Your 3600 x 2400 px image becomes 900 x 600 px, which is still plenty oversized for what's displayed. And at today's internet speeds, 220 kb will load really quickly even on mobile devices on "slow" cell networks.
For more context, 1080p resolution is often 1920 x 1080 px (depending on width), so even at 900 x 600 px, your image is a quarter the area of the screen. A 4k screen is 3840 x 2160 px (depending on width), so it's still about 1/15 the total screen size, which is still larger than what most people are doing to display it. (I should know, I'm using a 4k 49" TV as a monitor.)
Your current image has more pixels than a 4k screen can display, even though it's a different aspect ratio. All of that extra data is wasted.
And, speaking as a software developer who has done a lot of web dev, your images being on the same server as your website is very standard. About the only time you need to bother with a 2nd server is when you have massive amounts of images, which you don't have. I'm talking thousands, tens of thousands, or more images and you need a way to manage their organization or to offload/load balance the traffic. Using a 2nd server, Google Drive, OneDrive, Dropbox, or whatever just adds another layer of complexity that you don't need.
My website has a grid of images. Let's say there are 100 images in a 10x10 grid and each image is 50x50. I give the users the ability to scroll out so that this 500x500 grid becomes 20x20 grid at 25x25 resolution which is 400 photos or in which is 5x5 at 100x100 resolution for just 25 photos.
To be able to do this I must have all 400 images loaded from the get go. My issue comes down to how those images should be stored on the server. If I store all images at 100x100 then that could be say 4 megabytes of space. But if I store them at 50x50 that is only 1 megabytes of space but would be blurry at the higher resolution. Keep in mind that space is both the amount of data (and therefore time) to load a page and the amount of storage space required on the server.
My solution for this is to sacrifice server space by keeping multiple copies of the images stored at each resolution. When the page loads it takes 400 photos at the lowest resolution, 100 photos at the medium resolution and 25 photos at the highest resolution. Then when the user changes sizes it switches between which image it uses.
This is a simplistic example as ultimately I would like 5 (or more) levels of zoom and would be a lot more code. Just wondering if server storage is not an issue (if only) and I really wanted to push the efficiency of data usage (considering this site is aimed at mobile users), is this an acceptable solution? Or are there any other solutions which would be better or worth considering?
Does any one know which is going to be better for a browser loading time between these two options:
background-image:url('1by1px.png');
or
background-image:url('10by10px.png');
A 1px by 1px semi transparent png repeated for the div. Or a larger one say 10px by 10px.
There must be some kind of looping that has to be done to display the repeated image in the browser, and so I wondered if the image which is 1px by 1px causes alot of looping to get the image displayed that it may in fact be less speedy than a larger dimensioned image with less looping?
Of course the counter argument is image size is smaller for 1by1 compared to 10by10, but doesn't mean its better to be smaller because looping many times might not scale as good as looping a large image size slightly less often.
Does any know more about which would be better and how browsers handle situations like this?
When not repeating the background image, the time required to render depends on only the final scaled image, not the original one.
The image in a file is compressed as PNG format, but after being loaded by browser, it is in RGBA bitmap format (4 bytes for a pixel). When repeating a background, (let say on Intel x86), the native code of browser would use REP MOVSD to move the bitmap data from RAM to video memory (this is standard sequence, might be different on various implementations of graphics driver or specific GPU).
Assume that the dimensions of the HTML DIV which contains the background would be 100x100.
For the only-1 pixel image: the browser programme has to exec 10 thousand 'REP MOVSD' instructions.
For the 10x10 image: with each repeated image, the browser programme has to exec 'REP MOVSD' only 10 times (1 time calling to 'REP MOVSD' can render 1 pixel line (pixel row) of the image). So in this case, the number of 'REP MOVSD' instructions executed would be only 10x100 times (10 times in 1 image, 100 repeated images). This takes totally 1 thousand 'REP MOVSD'.
Therefore, the final background based on the bigger image would be rendered faster.
More notes:
The above explanation doesn't mean the performance is exactly 10 times better for the 10x10 image. A 'REP MOVSD' (with CX=9999 for example) is only 1 single CPU instruction but still requires 9999x4 bytes to be transfered through data bus. If using 9999 simple 'MOV's, that much of data still have to go thru' data bus, however, CPU has to execute 9998 instructions more. A more clever browser would create a pre-rendered bitmap for the background with replicated images; so each time it needs to transfer to video memory, it needs just only 100 'REP MOVSD' (100 is the number of pixel rows in the final background, assumed above) instead of 10 thousand or 1 thousand.
I agree with Paul answer.
I did few rough test with Google Chrome developer tool recently.
I used different size of semi-transparent png images on top of a background image and use page paint time to see how long do it take to refresh the screen.
Here is the result:
Time to refresh without -webkit-transform hack (rounded):
2x2 image : 65-160ms
10x10 image: 60-150ms
100x100 image: 55-135ms
1000x1000 image: 55-130ms
Time to refresh with -webkit-transform hack (rounded):
2x2 image : 40-120ms
10x10 image: 30-90ms
100x100 image: 30-90ms
1000x1000 image: 30-90ms
Just like what Paul said, bigger image is take shorter time to load(refresh), than smaller image.
But, it seem it is getting less effective after the image getting bigger than 10px. I don't see much difference between 100x100 and 1000x1000.
In my opinion, an huge image won't give you a noticeable result, and it might increase the loading time. So, I think any size around 10 - 100 is good enough for performance and loading time.
But still, different image might have different result, I think you should test your site with page paint time tool in Google Chrome developer tool for accurate result.
If there is a one-dimensional background that is repeated on a certain dimension, is there any mentionable difference in performance if the image is e.g. 1px wide versus 10 or 20 pixels wide?
I assume you mean a two-dimensional background.
I can't imagine that there is any noticeable difference, on modern computers. However, because bandwidth is still at a premium, especially on mobile devices, I think you would be better off conserving bandwidth by repeating a 1px wide image instead of say 2 or 3 px wide.
UPDATE: We just ran a test, unscientifically, but certainly perceptually relevant, in which one page rendered a 10px green square over a 10,000,000px square div, and another page rendered a 1px green square over the same size div. All styles are set with CSS, both pages had no other content. The graphics were loaded locally. There was absolutely no perceptual difference in the rendering in either Safari 5 for Mac, or FireFox 8 for Mac. Still, it's possible that there could be performance issues on certain models of older (crappier) smart phones.
You're probably not going to notice a difference between a 1px wide versus 20px wide background image, although there will be one. It's just the difference in file size that you have to download that you'd see. The larger the image, the larger the file size most likely, so it would take a fraction longer to initially download. Once it's in place you won't notice a difference either way.
I was wondering if anyone has done any tests with background images. We normally create a background that repeats at least in one direction (x or y or both).
Example
Let's say we have a gradient background that repeats in X direction. Gradient height is 400px. We have several possibilities. We can create as small image as possible (1 pixel width and 400 pixels high) or we can create a larger image with 400 pixels height.
Observation
Since gradient is 400 pixels high we probably won't choose GIF format, because it can only store 256 adaptive colours. Maybe that's enaough if our gradient is subtle, since it doesn't have that many, but otherwise we'll probably rather store image as a 24-bit PNG image to preserve complete gradient detail.
Dilemma
Should we create an image of 1×400 px size that will be repeated n times horizontally or should we create an image of 100×400 px size to speed up rendering in the browser and have a larger image file size.
So. Image size vs. rendering speed? Which one wins? Anyone cares to test this? With regards to browser rendering speed and possible small image redraw flickering...
The rendering speed is the bottleneck here, since bigger tiles can be put into the browser's cache.
I've actually tried this for the major browsers, and at least some of them rendered noticeably slow on very small tiles.
So if increasing the bitmap size does not result in ridiculously big file sizes, I would definately go with that. Test it yourself and see. (Remember to include IE6, as still many people are stuck with it).
You might be able to strike a good balance between bitmap size and file size, but in general I'd try 50x400, 100x400, 200x400 and even 400x400 pixels.
I found out that there may be a huge difference in the rendering performance of the browser, if you have a background-image with width of 1px and repeating it. It's better to have a background-image with slightly larger dimensions. So a image with a width of 100px performs much better in the browser. This especially comes into play when you use a repeated background-image in a draggable layer on your website. The drag-performance is pretty bad with an often-repeated background-image.
I'd like to point out that for the cost of sending down an extra few rows (1-2 only example here) .8k - 1.6kb (if you can get away with 8-bit) more like 2.4kb - 4.0kb for 24bit
2 pixel columns more means the required iterations required to blit the background in is cut down to 1/3 for up to 1.6kb (8-bit) or 4kb (24bit)
even 1 extra column halves the blitting required down to half the element width.
If the background's done in less than a second for a 56.6k modem I reckon it's lean enough.
If small dimensions of an image have a negative impact on rendering, I'm sure any decent browser would blit the image internally a few times before tiling.
That said, I tend not to use 1 pixel image dimensions, so I can see the image clearly without resizing it. PNG compression is good enough to handle this at very little cost to file size, in most situations.
I'd put money on the bottleneck being the image download rather than the rendering engine doing the tiling, so go for the 1 pixel wide option.
Also the 24-bit PNG is redundant since you're still only getting 8 bits per channel (red, green and blue).
I generally prefer to go in between, 1pixel wide will probably make your gradient seem a bit unclear but you can do something like 5pixel width which gives enough room to the gradient to maintain consistency and clarity across the page.. but I would suggest you can add more patterns and images to a single image and then use background positioning(css sprites) to position them because download a single image of say 50kb would take less time comapared to 5 40kb images since the browser makes fewer requests to the server...
I have not benchmarked this but I'd bet that on most modern computers the rendering won't be an issue whereas you always want to save on on the image download time. I often go for the 1px type of graphics.