I have a large, hi-def JavaScript-intensive image banner for a site I'm designing. What is everyone's opinion of using iframes so that you incur the load time only once? Is there a CSS alternative to the iframe?
Feel free to preview the site.
It is very much a work in progress.
I should also have mentioned that I would like the banner rotation to keep moving. When the visitor clicks on a link, the banner rotation starts over. It would be nice if the "animation" kept rotating, regardless of the page the user visits.Blockquote
Well, in that case I would strongly recommend not doing that. The only real way of achieving that is to have the actual website content in the iframe, which means that you suddenly have lots of negative sides to the site: not being able to bookmark urls easily due to the address bar not changing; accessibility concerns; etc
I think you'll find that most people won't care that it reloads again. Once a visitor lands on your website, they'll marvel at the wonderful banner immediately, and then will continue to ignore it while they browse your site - until an image they haven't seen appears and distracts them away from your content.
Keep the rotation random enough, and with enough images, and people will stop to look at it from whatever page they're on.
I find the main challenge with iFrame headers is resizing. Since the font in your header is of static size, I don't see a problem with using an iFrame. Although I'm not sure if it's really intensive enough to be worth it.
Well, the browser appears to cache all seven banner images upon the first load, and runs them out from the cache (for each subsequent page) thereafter. I don't think you have a problem :D
Try it out with Firebug's Net monitoring tool in Firefox.
This may work without CSS also, but if you use CSS to load the background and your server is configured correctly, the image should already only be downloaded once.
Usually the browser will request a resource by asking for it only if it has not been modified since the last time it was downloaded. In this case, the only things sent back and forth are the HTTP headers, no content.
If you want to ensure the image is only downloaded once, add an .htacces or an apache2.conf rule to make the image expire a few days into the future so that users will only request it again if their cache is cleared or the content expiration date passes. An .htaccess file is probably too excessive to use in your case, though results may vary.
You could have it load the main page once, then asynchronously load the other elements when needed (ajax). If you did that, an iFrame would not be necessary. Here is an example of loading only the new material.
While using IFrames as a sort of master page/template for your pages might be a good thing, IFrames have a known negative impact to searchability/SEO.
It might also be unnecessary in the first place because once your images are loaded the first time (and with the large high-def images you have on your site, that would be slow no matter what you do) the images are cached by browsers and will not be reloaded until the user clears their cache or does a Ctrl+F5.
Related
I have a strategy in mind for lazy loading images on a CMS (Sitecore) website, and I'm wondering if I will run into problems with it, since I am not finding examples of it being done.
The point is to improve performance, but reduce the side effect where users can get annoyed by images that are incomplete as the page is scrolled.
The strategy is using loading="lazy" on all images on the page, or only images below the fold, and upon page load, dynamically swap lazy to auto on all of these elements, from which point the browser will decide when to load the images by its own prioritization scheme.
The point is to prioritize images above the fold, but once the prioritized images and everything else are loaded, then tell the browser to load images by its own default loading behavior, so the user will be less likely to encounter incomplete images.
Are there problems I may run into doing this?
I can't imagine I am the first person to try this, but I am not finding examples in my search. Is this strategy established and documented anywhere?
The strategy is using loading="lazy" on all images below the fold, and upon page load, dynamically swap lazy to auto on every image element, from which point the browser will decide when to load the images by it's own prioritization scheme.
You don't need that to do. The browser know better when he should load the image. Just stay with lazy.
Are there problems I may run into doing this?
Yes! When you don't define a width & height for the image. There are some webpages which use achnor navigation. When the browser don't know how much space the image will take, then can happend that you will get some incorrect position when navigating.
Also there are some sideeffects that will load the image later then expected. Inside a slider as an example. But the benefit to not load the image is much more enjoyable then not to lazy loading the image.
Read more about the specific use-cases in this wonderful blog article:
https://web.dev/browser-level-image-lazy-loading/
I am looking at disadvantages of lazy-loading images, and I must be hyper-thorough because we are considering implementing loading="lazy" on many/most images in the site. The reason for that is that I believe I have a strategy that should work.
We are using the browser-native loading="lazy" attribute, since we dropped support for IE recently. Wow, I know.
We are setting all images above the fold to eager, and all images below to lazy, across the entire site.
Then we are listening for the page load event and running a script that converts every image with loading="lazy" to loading="eager" (or auto). So images below the fold will get loaded too, probably in most cases by the time the user scrolls (at least using modern internet connection speeds). The page load event fires after all eager-loaded images have completed, but may/should fire before lazy-loaded images have started, so that is our opportunity to trigger loading below the fold.
One known disadvantage is that lazy-loaded images can cause a layout shift as the user scrolls, since the browser doesn't know the dimensions until the image starts loading. Another disadvantage is that users may be annoyed by images that are not loaded by the time they scroll to the image. This solution addresses both of those problems by converting remaining lazy-loading images to eager as soon as the prioritized images are loaded, to reduce the chance of the user encountering these issues.
There is also the possibility that there may be specific cases where pieces of JavaScript are waiting for an image to load in order to do something with it, and that can sometimes block rendering. Let's treat that as a side issue. I think it's unlikely we'll encounter that in this site, and we'll fix it where it occurs.
A side note, I have also devised a script that observes elements being populated or manipulated on the DOM by external scripts, and converts any newly-added img elements to loading="lazy" (if it occurs before page load), so I am able to guarantee lazy loading on all img elements on the page, and it DOES yield Lighthouse load performance gains of several points.
I am so far not finding many serious and/or likely problems from lazy-loading every or most images on a page, given that it is handled with the strategies that I have devised.
My question is what am I missing. Could this strategy have gaps?
What other considerations do I need to think about? Because I don't want my decisions to cause problems on the site I am working on.
When internet connection is very quick, things are also loading quickly and the user might not even see the status before the images are loaded. However, things are not always so rosy, there might be too many people using the internet and occupying all the bandwidth they can with watching videos, listening to music, chatting with friends.
Your problems start arising when
the users are using too many devices
there is an internet outage during the load of your page
an image is unavailable or slow to load (a very slow third-party UI, perhaps)
Usually, if your design works well and handles these cases in a user-friendly way, then users will notice there was a wait/outage, of course, but will probably not link that to your site. Yet, if your design looks ugly during these phases, then the users will remember that there was an outage/slowness of internet and how ugly your page was.
Since this is something every developer wants to avoid, it makes sense to treat the internet as something that usually works, but always has the potentiality of being down or slow.
As a result, if you know what pictures will appear in the viewport and what pictures will be shown only when the user scrolls, then you can eager-load the pictures the user will see first. Of course, it is not always easy to know what pictures will appear in the viewport, especially if your page looks very differently on different devices. Yet, you could divide your content into two main sections:
the section that is shown even during page load
the section which will be shown only when the page load is complete
you can totally hide the second section and then there would be no visual problems.
Another way to handle this is to know in advance (on server-side) the dimensions of the pictures, hide the picture tags while they are loading and show some placeholder (some "loading" gif, for example) in the place where the pictures will appear and have a load event for all images that are hidden this way which would make sure that the "loading" placeholder will disappear and the actual image appear when the image is loaded. This would ensure that your layout's visual structure is the exact same while it does not have all the images to show yet as when all the images were fully and successfully loaded.
What you may not know if you've never used browser-native lazy loading is that it does not necessarily improve initial load size/time on shorter pages, because it still initiates loading anything closer to the viewport than 3000 pixels, even before the window load event fires. This is what is considered too eager.
Info about this issue: https://calendar.perfplanet.com/2019/native-image-lazy-loading-in-chrome-is-way-too-eager
That can make it useless against Google's Lighthouse performance metrics for shorter pages.
So we are implementing the old-fashioned non-native lazy loading where we have complete control via JavaScript. Our images are served like:
<img data-src="some-image.src" />
<noscript>
<img src="some-image.src" />
</noscript>
...And using JavaScript strategy similar to what was described in the original question here, in addition to the common technique for swapping Image.dataset.src into the Image.src property, or we many use lazySizes.
But I don't get a few things about the functionality of browser-native lazy loading. Particularly, why the browser wouldn't prioritize lazy images above the fold over lazy images below the fold, and not load any lazy image below the fold or fire the load event until everything is loaded above the fold.
And I don't get why lazy loading can't be set with CSS. It would be great if we could apply the loading attribute to sections of a page by CSS selectors alone. Instead we're forced to handle it either with JavaScript or on the server. With CSS it would be as simple as loading: lazy;.
I'm going to look into if these ideas are proposed anywhere. I may also post the code we use in the end.
The thumbnails on my photos page take a long time to load, then if you scroll down the page and back up, they have somehow vanished and need to reload. I'm using an old version of chrome on Windows XP, so I'm sure that's half my problem, BUT, it still does this on my cell (galaxy S5). I'm a novice coder so please go easy on me lol. Here is the link to my website and the photos page:
http://www.mikemicalizzicontracting.com/photos.html
I can't really help you about your precise questions, as we don't have your code, but I am in a good mood so I'll just give you some tips to make your website quicker.
Some tips for optimize your images :
1) Resize your images
For now your images are displayed in 207 * 154, which is small, but you download them in their original size. You should resize them so the size of the image (in bits) would be much lower.
You can do that with a lot of online tools, or write a simple script for that in bash for instance. I think you will find a pre-made solution for the script very easily, or just have to download imagick (I am not sure of the name). This solution by scrip also depends on your distribution (wether you are usinc OSX, Windows, Linux..)
2) Cache your images first
It is always painful for the user to wait for images to display. So what you need to do is use browser cache (if you are novice you wil have some trouble but it will be worth it) to store the images data and then display them from this cache.
So the strategy is :
If there is the image in cache, just display it from there
If there isn't, download it from your server
once it is loaded, put it in cache; then display it from there.
3) (More advanced) Preload the images
If your home page is very easy to display (not a lot if images, not that much script to run etc), you can start download some images in the client and just store them in the cache.
This task should always be a second-hand task, it means it should not slow your user navigation. So depending on what the user is doing, you may will have to pause the request and start it again.
If the user go on the photo page when an image is currently downloading for cache, you don't need to start it all over again, just continue.
This last tip can be long to develop, but this is a good thing to do when you want to display very good quality images or just plenty of them.
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.
I've been working on a website, and we've managed to reduce the total content for a page load from 13.7MiB's to 2.4, but the page still takes forever to load.
It's a joomla site (ick), and it has a lot of redundant DOM elements (2000+ for the home page), and make 60+ HttpRequest's per page load, counting all the css, js, and image requests. Unlike drupal, joomla won't merge them all on the fly, and they have to be kept separate or else the joomla components will go nuts.
What can I do to improve load time?
Things I've done:
Added colors to dom elements that have large images as their background so the color is loaded, then the image
Reduced excessively large images to much smaller file sizes
Reduced DOM elements to ~2000, from ~5000
Loading CSS at the start of the page, and javascript at the end
Not totally possible, joomla injects it's own javascript and css and it does it at the header, always.
Minified most javascript
Setup caching and gziping on server
Uncached size 2.4MB, cached is ~300KB, but even with so many dom elements, the page takes a good bit of time to render.
What more can I do to improve the load time?
Check out this article.
http://www.smashingmagazine.com/2010/01/06/page-performance-what-to-know-and-what-you-can-do/
If the link gets removed or lost the tools mentioned are:
YSlow (by Yahoo)
Google's Page speed
AOLs web page test
Smush.it (Image compression tool)
It sounds like you've done a great job of working around the real problem: those giant graphics. You can probably squeeze some more efficiency out of caching, minifying, etc., but there has to be a way to reduce the size of the images. I worked with a team of some of the pickiest designers on Earth and they never required uncompressed JPEGs. Do you mean images cut out of Photoshop and saved on full quality (10)? If so, the real solution (and I appreciate that you may not be able to accomplish this) is to have a hard conversation where you explain to the design company, "You are not your users." If the purpose of the site is to only impress other visual designers with the fidelity of your imagery, maybe it's ok. If the purpose of the site is to be a portfolio that gains your company work, they need to re-asses who their audience is and what the audience wants. Which, I'm guessing, is not 2 minute load times.
Have you enabled HTTP Compression (gzip) on your web servers? That will reduce the transfer size of all text-based files by 60-90%. And your page will load 6-10x faster.
Search StackOverflow or Google for how to enable it. (It varies per server software: Apache, IIS, etc).
Are all the DOM elements necessary? If they are, is it possible to hide them as the page loads? Essentially, you would have your important need-to-be-there dom elements render with the page, and then when the document is loaded, you could unhide the rest of the elements as necessary
$('.hidden').removeClass('hidden')
Evidently, there are plugins for compressing and combining JS/CSS files:
http://extensions.joomla.org/extensions/site-management/site-performance
http://extensions.joomla.org/extensions/site-management/site-performance/7350
I would say you can't do anything. You're close to the absolute limit.
Once you get to a critical point, you'll have to compare the amount of effort you'd need to input into further compressing the site against the effort of throwing the most bandwidth expensive components out the window. For example, you might spend 20 hours further compressing your site by 1%. You might also spend 40 hours on throwing the Joomla theme away and starting again saving 50%. (though probably not).
I hope you find an easy answer. I feel your pain as I am struggling to finish a Drupal project than has been massacred by a designer who hasn't implemented his own code in years and has become institutionalized in a cubicle somewhere near a tuna salad sandwich.