We Keep Coding

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.

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.

Http request - IMG vs TEXT?

The timeline shown here (captured using IE’s F12 developer tools) illustrates how IE handles a page
where an <img> tag is located after of a bunch of text :
The second row shows the retrieval of the image. Since the image is small, all of the image data is included with the HTTP response headers in the same packet.
However - The next timeline shows what happens when the <img> tag is located close to the beginning of the file so that it’s in the first packet of data received by IE:
However, the request for the image starts shortly after the first packet of HTML arrives.
As a result, it takes less total time to retrieve the page and the image
But (IMHO) it is better to put images (with defined dimensions) on the bottom of that page. ( so that the page will load faster)
However - by my example it shows that the page is loading faster when the img is on top.
What am I missing ?
P.S. my question is a briefly summarized text of this section

You are missing several points.
First, the best practices are not only about downloading, but about rendering as well, because if the whole page is downloaded for 3s but in require another 2s to be rendered, the user waits 5s, not 3s. I don't know best practice for putting images at the bottom (there is such for scripts), the best practice I know is to include width and height attributes so you do not block rendering while the image is being downloaded.
Another thing you are missing in your test is parallel downloading, as browsers limit the number of concurrent connections and you are testing with only one image. Make your tests with more images, or best - with a real web page, in order to have reliable results.

I'd rather bother about lessing number of connections, - loading whole page at once. Split interface and content parts. Once interface loaded - it can ask user to wait and inform him about connection speed. Then put a progress bar and inform user about how things go.

Cached content for image element kept in browser after being removed and added again

We are developing a web app where the interface uses AJAX/Javascript entirely.
There are certain dynamic images with cache expiration times of access + 15 minutes. So, when the images are accessed normally they are cached for 15 minutes and then after this time the browser will fetch a new version, caching again for 15 minutes and so on.
The issue is that in this AJAX setup, even when image elements are removed and then added, the newly added image element (which could be over 15 minutes later, when the browser would normally fetch the new image version) does not contain the new content. i.e. once the image is loaded in once, even after the element is removed, if this element is re-added at any other stage without the page being changed, only the originally loaded version will display.
So far this issue is with Chrome, I've not tested other browsers yet. The image appears to sort of be held in "memory" even when the image element is removed, the image shows under "resources" in Chrome developer tools - again, this is long after the image element specifying this image source has been removed.
What can I do about this? The only solution so far is to change the image filename on subsequent loads (the old query string trick perhaps). The issue here is that these images then stack up the in the "resources" tab of developer tools, as though they're being held open, despite the image elements being removed.
Hope this made sense. Any thoughts? I really just want Chrome (and maybe other browsers that have this issue) to load the image properly regardless of the source on new image elements. That is.. the route of check cache, if expired fetch from server and cache again.
Cheers

The way I've solved this is to append a random query string on to the path of the image. For example:
<img src="myimage.gif">
becomes
<img src="myimage.gif?a=randomnumber">
The random number will force the browser to grab the newest version.

Resource responses is cut

I have a web app which displays a Java Script image carousel.
Showing one image at a time for n seconds.
When the html page (index.html) loads it loads all n images in an hidden parent html DIV and the app (JavaScript) is responsible for showing and hiding the parent divs for the images at a given interval.
This usually works fine, but some times (randomly) only half of the image is loaded (eg. just half of the image is displayed on the screen).
Sometimes only "half" of the index.html response is loaded making the HTML kode to bleed out to the display.
Unfortunatly I do not have any tools like Firebug etc. to debug the problem yet since the screen is a kiosk (screen hanging on the wall)
To me this seems like a network problem but I am no network administrator so I will just be guessing here.
As I said this happens randomly.
The image starts loading but only half of the image. Sometimes after maybe 15 seconds the rest of the image is suddenly displayed.
If this could be a network problem the what could it be?
Best regards,
bob

Sounds like it could be a network issue. Why not try and cache the images on the browser so you don't have to wait for them to load every time. Also try looking in the Firebug/Web Inspector Net panel and you should be able to see if the browser is waiting on a network response or not.