The conditions:
It's a movie website with approximately 1000 images of 15kb
Approximately 70% of all images will be loaded on a page visit
Images will have a long expiry date.
I think I will chose CSS-sprites because most images will be loaded by the visitors any way. But the CSS-sprite of all images are 9MB and 15000x2000px. Even if I devide it into 3 sprites it's 3MB :S
Maybe such big sprites will cause some problems?
Will images be cached by the browser even if they are 3-9MB?
Will the big pixel dimensions be any problem for the browser?
Lazy load or CSS-sprite, what should I chose?
Please advice me!
Yes this will cause problems:
Due to the sprite size and dimensions, it will significantly consum cpu power
if you use it often on one page, it could even decrease scrolling and at least DOM manipulation actions
9MB is too big, do you have a link to that sprite ?
The browser will cache it, if the headers are set correct, that is not the problem
And you dont want to load a 9MB Sprite that is mandatory for a site !!! Mobile ?!?!!
Gekkstah
Related
We tried to test the performance of two images on site’e homepage. We tested one image then the other one. Now the issue is the image which is having large size, better quality as well as large dimensions is giving us better speed results as compared to the image having small size and less quality even though it should have been opposite to it but help me figure out why is that. The image is the first image on site’s homepage.
Speed results: https://pagespeed.web.dev/report?url=https%3A%2F%2Fhijrahpress.com%2F
Image that gives better results is named with large(having large size, dimensions and high quality) and other as small.
Large image:https://ibb.co/S6cK7sj
Small image:https://ibb.co/cFFhvdk
Large image currently used on homepage.
The suggestion are to convert the png image to webp.
It should be sized to fit your page. The image size on your webpage is 600 x 900.
I converted for you. This is much improved.
arabicgrammar.webp 600 x 900px
I have a tableview that displays user uploaded PFImageViews. But the images load slowly because they are high res.
What is the most efficient (least costly) way to make images load quickly, while keeping the image size the same.
Current Approach:
Save the image twice (original file and low res file)
When displaying PFImageView, display the low res image
first, then asynchronously load the original image.
Is this the best approach?
Method 3:
For everything not in view of the user, do not load the images (delayed loader). That saves you the bandwidth and CPU to give the user the best possible experience.
I'm trying to optimize the loading time of my website.
Does requesting the same image in different places of the code increase load time?
For example, I'm using an image as background of a button and I'm loading the same image in different places of the website.
Is this a problem or since the file is the same in all the buttons the browser only loads it once?
If it's a problem, how can I optimize it? Thanks a lot!
no, repeating the same image multiple times should load it only once. You could even go further and actually use css sprites to have multiple images in one (one image which is a grid of images as a background within a smaller containing div and move it around with background position property)
I used to animate my CCSprites by iterating through 30 image files (rather big ones) and on each file I changed the CCSprite's texture to that image file.
Someone told me that was not efficient and I should use spritesheets instead. But, can I ask why is this not efficient exactly?
There are two parts to this question:
Memory.
OpenGL ES requires textures to have width and height's to the power of 2 eg 64x128, 256x1024, 512x512 etc. If the images don't comply, Cocos2D will automatically resize your image to fit the dimensions by adding in extra transparent space. With successive images being loaded in, you are constantly wasting more and more space. By using a sprite sheet, you already have all the images tightly packed in to reduce wastage.
Speed. Related to above, it takes time to load an image and resize it. By only calling the 'load' once, you speed the entire process up.
I've noticed that when dynamically creating a large canvas (6400x6400) that quite alot of the time nothing will be drawn on it, and when setting the canvas to a small size it works 100% of the time, however as I don't know any better, I have no other choice than to try and get the large canvas working correctly.
thisObj.oMapCanvas = jQuery( document.createElement('canvas') ).attr('width', 6400).attr('height', 6400).css('border','1px solid green').prependTo( thisObj.oMapLayer ).get(0);
// getContext and then drawing stuff here...
The purpose of the canvas is to simply draw a line between two nodes (images), which are within a div container that can be dragged around (viewport I think people call them).
What I "think" may be happening is that on a canvas resize it emptys the canvas, and that is interfering with the context drawing, as like I said previously it works all the time when the canvas is alot smaller.
Has anyone experienced this before and/or know any possible solutions?
That is an enormous sized canvas. 6400 x 6400 x 4 bytes per pixel is 156 MB, and your implementation may need to allocate two or more buffers of that size, for double buffering, or need to allocate video memory of that size as well. It's going to take a while to allocate and clear all that memory, and you may not be guaranteed to succeed at such an allocation. Is there a reason you need such an enormous canvas? You could instead try sizing your canvas to be only as large as necessary to draw the line between those two divs, or you could try using SVG instead of a canvas.
Another possibility would be to try dividing your canvas up into large tiles, and only rendering those tiles that are actually visible on the screen. Google Maps does this with images, to only load images for the portion of the map that is currently visible (plus some extra one each side of the screen to make sure that when you scroll you won't need to wait for it to render), maintaining an illusion that there is an enormous canvas while really only rendering something a bit bigger than the window.
Most browsers that implement HTML5 are still in early beta - so it's quite likely they are still working the bugs out.
However, the resolution of the canvas you are trying to create is very high .. much higher than what most people's monitors can even display. Is there are reason you need it quite so large? Why not restrict the draggable area to something more in line with typical display resolutions?
I had the same problem! I was trtying to use a big canvas to connect some divs. Eventually I gave up and drew a line using javascript (I drew my line using little images as pixels- I did it with divs first, but in IE the divs came out too big).