Make jquery lazyload plugin work inside the viewport - javascript

The lazyload jquery plugin delays loading of images in long web pages. Images outside of viewport (visible part of web page) wont be loaded before user scrolls to them.
The problem is I have a thumbnail gallery with about 40 small images, 10 per line.
If I load the site, I can see 3 rows of images (30 images in total). The plugin does wonders with the other 10, but I still get 30 HTTP requests at once.
Can this plugin be modified to delay images in the viewport? maybe in groups?
Display the first 10, wait half a second, display the next 10, wait again and so on.
P.S. Lazyload has an option to delay loading all images until the DOM is ready, but if scripts like jquery or others load a bit slowish sometimes - I will see a site with no images.
Here is a link to the plugin source code.

If you manually add a class to each image in the row of 10 and a separate class to the images in the row after and so on, you can trigger a load of each row like so:
$(function() {
$("img").lazyload({
event : "timedload"
});
});
$(window).bind("load", function() {
setTimeout(function() { $("img.row1").trigger("timedload")}, 1000);
setTimeout(function() { $("img.row2").trigger("timedload")}, 2000);
setTimeout(function() { $("img.row3").trigger("timedload")}, 3000);
setTimeout(function() { $("img.row3").trigger("timedload")}, 4000);
});

If you are only worried about the request amount you can use Image Sprites to bundle your images.
For example you can bundle the first row in one sprite, the second in another and so on. This reduces your 40 requests to 4!
Of course this requires that
images are either static, so each user sees the same images or
some kind of server sided "Image Sprites" generator. However neither
Google nor Facebook are using a server sided "Image Sprites"
generator to bundle their images

Related

Loading screen using JavaScript changes nothing on a phone

I have a simple question.
I'm trying to get ride of the blank page when I load a html page with 2 videos in it.
I searched for some solutions and the most popular I've found seems to be this one (With some css).
<script>
// Wait for window load
$(window).load(function() {
// Animate loader off screen
$(".TheDivClass").fadeOut("slow");;
});
</script>
But there is no noticeable difference when I load my website using my phone (on chrome or safari) and I was wondering why. It still loads in a blank page during at least 50 sec and then the loader icon shows up for 0.5 sec.
Should I put the link of the site to show what I mean?
It's a portfolio :)
https://velynns.netlify.com/
The Solution :
// Wait for window load
$(window).load(function() {
// Animate loader off screen
$('#Video1').load('LoadVideo1.html');
$('#Video2').load('LoadVideo2.html');
$(".se-pre-con").fadeOut("slow");;
});
Where LoadVideo1 & LoadVideo2 contains the video tags.
Your videos must be causing delays on the loading of everything all together.
A better way to handle this situation might be to remove the videos all together from the website first, but keeping the empty div's to place the videos in after loading your page.
1 - Show the "page loading" animation
2 - After loading animation is showing, load the videos into the website
3 - Once the videos are loaded, then hide the page loading animation.
$(window).bind("load", function() {
$('#movie-div').load('movie.html');
});
Do something like this to load the video into the empty div after the page is loaded up.

<img> fails to load image with error GET 0()

SITUATION:
My page has about 500 <img> elements that are dynamically generated and populated with image urls from an API request that refreshes the data once per hour.
PROBLEM:
Every few page loads, a good amount of images fail to load the image with error code 0().
WHAT I TRIED:
I also tried putting all the images directly in one of my website's folders and loading them from there and the same behaviour happens.
Some times all images load without any issue, sometimes a good number of them fail to load.
QUESTION:
How can I make sure the images always load ?
P.S.: I checked the image urls when the images fail to load, the urls are correct.
Screenshot attached.
EDIT:
To be clear, my question has most likely nothing to do with the requests themselves since the image urls are properly loaded inside the <img> tags, it's the images that fail to load, not the urls.
It might be difficult to figure out why some images sometimes fail to load. One strategy could be to check if all images were loaded.
See: Is it possible to reload a specific image if it did not finish loading after a preset amount of time? javascript/jquery
Here's the sample code from the accepted answer that should work for your scenario:
var images = $('img'); // Get all images. (you'll want to modify the selector
// to work with only the desired images)
images.load(function() { // Add a load event hander that removes
images = images.not(this); // each image from images once loaded.
});
setTimeout(function(){ // After 10 seconds, iterate over each remaining
images.each(function() { // image, reloading each one
// reload this image
});
},10000); // run after 10 seconds

Pace.js not waiting for iframes to fully load

I'm using pace.js on my site and I'm having difficulties with pages that have iframes. Is there a way to make it so that pace.js takes into account the content loading inside of those iframes?
I've tried setting the paceOptions to wait for the iframe selector to load before deciding that the page has fully loaded, but it seems to just recognize that an iframe is on the page, but not that the content inside has been rendered.
This is what I currently have:
<script>
paceOptions = {
elements: {
selectors: ['iframe']
}
}
</script>
<script src="include/pace/pace.min.js"></script>
You can add class or id to your iframe and use those in your pace initalizer.
pace-options = { elements: {
selectors: [".class1", "#id1", ".class2"]
}
}
I've had this same issue with iframes. Especially when you want two or more frames to play live video feeds simultaneously.
I haven't come up with a proper solution, but I've been toying around with the idea of letting the whole page load with the iframes autoplay set to false, and then having a separate script start both of them as simultaneous as possible.
If it's a live video feed, I don't know if there are time stamps or not, or if it would be possible to pull the timestamps and have the two separate frames sync up like that. Just food for thought.
My problem has been, even if I get the frames to start together, network latency, etc causes the two separate live feeds to get off kilter.

How to create a loop in javascript (for use in Chrome -> Console)

I am viewing a webpage with a lazy load structure (similar to facebook's wall), such that when a user loads the page and scrolls down, more content is loaded if available.
I want to view this page in Chrome, and inject a script via the console to infinitely scroll down the page so I can get the last available entry.
This code works for 1 instance:
window.scrollTo(0,document.body.scrollHeight);
How can I make it scroll infinitely with 1.5 secs between scrolls?
If you want to repeat some lines of code over a set interval, then you should look at window.setInterval(). For your case you could do
var scrollInterval = window.setInterval(function () {
window.scrollTo(0,document.body.scrollHeight)
}, 1500);
Although that's probably not the best way to go about it because god help you if you do it on a page that has thousands of posts available like facebook. If ever you want to stop it you can enter into the console:
window.clearInterval(scrollInterval);

Preloading images in Firefox aren't being retrieved from the cache on the same page load

Some context, I am running a script on a website's home page to swap background images on a timer. We decided it would be better to attempt to implement preloading of the images, which prompts the following issue in Firefox:
Preloading images on the first page load will not prevent the browser from loading the image from the original source again instead of the cache. Oddly though, refreshing the page will successfully cause the image to be loaded in from the cache.
The JavaScript that runs on page load takes all of the image URLs, and attempts to preload them via calling (new Image()).src = 'http:// ...'; for each one.
Inspecting the page load revealed that the images would be loaded in on page load, but then the image would also be loaded in again when the slide was revealed.
Test Image Link (SO reputation restrictions): http://i.stack.imgur.com/E9KLM.png
In the image, the images -66.png, -21.png, -63.png, and -83.png were preloaded from the JavaScript, but are then requested again when the slider reveals that slide.
What's also strange is that the bottom images look like they were queued to be loading in since the page was created. Maybe it's because this takes priority over the script that was loaded once the document was ready?
To finish off, if I was to refresh the page and jump to a slide that was preloaded with the images, but never revealed, it is shown to be loaded from the cache like it should have been originally.
My theory is that the original background images are maybe declared to needing to be loaded from the server when the page is first loaded, but aren't actually loaded until the slide is revealed. On document ready, when the javascript preloads the images, they're not cached yet so they need to be loaded from the server. Then a slide is revealed and the browser tells that image that it needs to be loaded as originally declared.
Does anyone know why this situation is occuring? If so, are there any solutions to resolve?
I have an idea that involves adding the image URLs as a data-url attribute instead, and then having javascript preload them and add them as background images at that point, but I haven't tested this yet.
For those interested, we were not able to find a perfect solution for this.
What we did notice, however, is that the images were being pulled again based on their size. The larger the image size, the more likely the image was not fetched from the cache when the image was shown to the user.
We semi-resolved this issue by compressing our background images even further, and then greatly limiting the amount of images preloaded on the first page load. We found that these two steps greatly increased the changes of the images being pulled in through the cache when needed. It also saved more bandwidth and improved page loading times in general by a significant amount.

Categories