简体   繁体   中英

Web Page Images Load Time

I have an application for touch devices like iPhone and Android. The application is built using HTML, CSS and JavaScript totally. When the application loads, it shows blank elements of those who has background-image set for approx. 0.5 seconds. And after some time those elements are being filled with images which is why because the images are taking time to load to the device.

I have all images as Base64 data URI in the css file named images.css (893 KB) like you can see below.

.icon { background-image: url(data:image/png;base64,bytes.....; }
.img1 { background-image: url(data:image/png;base64,bytes.....; }
.img2 { background-image: url(data:image/png;base64,bytes.....; }
.img3 { background-image: url(data:image/png;base64,bytes.....; }

The app works but images are around 60s and how can I preload them before showing the views? Or how can I test if the images.css file is loaded to make sure the images are all loaded?

That's a rather HUGE css file. Base64 is hideously inefficient space-wise, so you could definitely speed things up by using proper image files, and if need be, CSS sprites. For an example of how those look, you don't have to look any farther than SO itself. The nifty icons all over the page come from a single image file http://cdn.sstatic.net/stackoverflow/img/sprites.png?v=4 which is loaded into fix-sized divs with appropriate height/width offsets to display only the small chunk required.

The benefit of using data:image/png;base64 is to reduce requests to the server for many small files. IE 20 small images means 20 http requests limited to a few connects at a time.

You can use url(data:image to speed up performance by eliminating those requests or in some cases combine images and clip the edges with css to get the right background element or in some cases it is best to split large images up because by doing so they can compress down to smaller images.

However neither method is a magic bullet that always improves performance. There are trade offs that make optimization an art form. If your images.css were 100K and contained 20 or 30 images likely you would see and improvement.

The first question I would ask myself at this point if I were working next to you would be. Which images are used on the page before the visitor interacts with the page? Performance optimization is also like an illusion performance. If the page is drawn almost instantly and the page is responsive to movement then the illusion has been accomplished - even if in reality behind the scenes there are mouse over objects still being downloaded.

How much content can you download behind the scenes?

http://code.google.com/speed/page-speed/docs/payload.html#DeferLoadingJS

Take the images that you need to show to present the page out of that large CSS file. It is way to big, Can you compress it on the server?

Discern what images needed to render the initial screen instantly an Iphone screen resolution is not that high. After optimizing the initial screen then optimize for the rest of the material which the visitor does not see until he interacts with the page.

Much of the art of optimizing for performance is an illusion ... data:image/png;base64 because it is uncompressed is part of that illusion. It appears to download faster when coded in html or CSS files that are small. Logic dictates that if the file size increases so do the download time.

Hard logic is ... "a 500-byte HTTP header request could take the equivalent time to upload as 10 KB of HTTP response data takes to download." http://code.google.com/speed/page-speed/docs/request.html ... unless the base64 encoding does not add more than 10KB to the image file size you are slowing it down by placing it into a data URI.

The only use for a CSS that large is to deceive the user by having him see a quick initial screen and saying: It appeared to download in a snap? wow how did they get so much material onto the iphone so quickly? The answer is it was a trick - the material you thought downloaded quickly was defered.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM