The issues is with existing ASP.NET MVC 4 project. The View itself is not that big but there are also several service calls and what happens is that people with slow internet connection reports that for some period of time when they request the page it stay unresponsive, so they don't know if the content is loading or something went wrong.
So in general, what I need is a way to show a loading image as the very first thing from this page (or at least fast enough) so even if it takes some time for the browser to download the full content, at least the user will know that something is going on.
However it seems that this is not as trivial as it sounds. I came up with two ideas, one was already proven to not work in all cases and the second is also something that many people doesn't recommend.
What I've tried was to use pure JavaScript in the <head> tag like so:
<html>
<head>
<script>
document.write("<div style='margin-left: 50px; margin-top : 50px;'>LOADING...</div>");
</script>
</head>
Of course the styling is just to get the idea. This seemed like it was working until recently when on a minor build of IE 11 the page broke which after some investigation was proven to be due to the usage of document.write() inside the <head> tag. Even though this seems to work on most browsers and versions the fact that it's a potential danger requires a change in the approach.
The second idea is pretty similar to this, again - writing directly in the <head> tag but this time instead of using document.write() just putting the html markup directly there. From what I've read this is also a recipe for disaster so I don't even want to try it, but those are the two ideas that I could came up with. Everything else just doesn't work for slow internet connections since the mainstream solutions relays on the fact that some part of the DOM is already loaded so you can use it to apply behaviour/style.
I hope I'm not the first one that got this problem so I would appreciate any suggestion on how to solve this issue. Since I am using ASP.NET MVC 4 there was an idea to use a dedicated controller with view which to get called first just for the sake of showing the loading image and then moving to the requested view. Even though this idea seems interesting I didn't have the time to think it over, it also sounds a pretty complicated, but anyways, all help will be appreciated.
When faced with the same issue, we did as you mentioned: Load a super-light-weight page first with a tiny loading icon & "Loading..." text, then called back to the server to pull down the heavy content in chunks using ajax.
If you content is really heavy, it's also worth mentioning that you need make sure you have gzip compression turned on at your web server layer also.
Don't block the rendering of the DOM. Load the page and call your scripts right before the closing body tag and attach to an event like DOMContentLoaded or window.load (if you're using jQuery, that would be $(document).ready). In other words, you should allow the page to load completely, even if it's empty, before running any of your JavaScript.
Then, don't worry about writing the "Loading" div dynamically. Just include it in the rendered HTML and hide it initially. The first thing your JavaScript will do, before issuing any AJAX calls, is to show this "Loading" div.
Related
This is largely a theoretical question, for which I do have a practical purpose. I first am looking for some conceptual answers before diving into practice, as perhaps the idea itself does not make sense.
Imagine a slideshow that is entirely javascript-based. Users see a large image on their screen and click to move to the next large image. Upon clicking, the next image is loaded and inserted into the DOM, replacing the previous one.
I recently learned that prefetching directives can help in speeding up the loading of resources that are very likely to be used next. Note that I said resources, not pages. The slideshow is a single page.
In an image slideshow, it is very obvious that it is likely that the next image is needed, thus if image1 is on screen, I could dynamically add this to the DOM:
<link rel="prefetch" href="http://img.mysite.com/img2.jpg">
My questions regarding this idea:
Would it work at all? Do browsers accept this directive when it is dynamically inserted in the DOM at run-time? Would it trigger the prefetch?
Is there a possibility of timing conflicts, where if prefetching would indeed work, it did not finish in time before the use does the "load" without prefetching? Obviously this can happen, but will it have unwanted side effects?
Will specific events such as image onload still work correctly, or are they never triggered in the case of a successful prefetch (assuming it works at all)?
I did a lot of searching but I am unable to find answers on this specific situation of dynamically injected prefetch hints.
onload always gets triggered, even if the image is coming from cache. You do not have to worry about timing effects or race conditions, any such behavior would be a browser bug.
As mentioned in comments, rel=prefetch is not the only way of achieving pre-fetching. It works though even when dynamically inserted into the DOM. After all, you could fetch the image without the prefetch attribute and hide it.
I've written a small HTML5 page that I need to be able to support multiple languages. I've implemented the language control by making the page load a JSON file into memory (in the HEAD) and then running a jQuery command to change the text of any element as required.
Everything works fine except that as the change is being called post render (if the document ready function) there is a slight flash as the language gets changed.
Is there an event that is called before the page is rendered but after the DOM is available? If not, are there any suggestions to change implementation.
Cheers..
UPDATE
I've found a few answers to this on other sites. The general consensus appears to be that this isn't possible as most browsers render as they parse. The workaround that is suggested is to hide (display:'none') the body in script and then show it (display:'') after the updates in the document ready function. It sort of works for me although isn't 100% perfect.
Sounds like you are having an issue with FOUC (Flash Of Unstyled Content)
There are a few ways to get around it. You could add this to your body:
<body class="fouc">
And then have this CSS:
.fouc{display:none;}
And finally this script:
$(function(){
$('.fouc').show();
});
This works by initially hiding the page, and then once you are ready, turning it on with javascript. You may need to ensure your manipulation occurs ahead of the $('.fouc').show(); call.
One effective solution, though not the one you are probably looking for, is to use OUTPUT BUFFERING ... What is output buffering?
This is a bit of an odd issue I'm having. I've been using John Resig' micro-templates for a meeting minutes application, and it seemed to work well, but lately I've been having an issue.
Basically the application fetches some JSON from an ajax call, and then uses the templating engine to generate a table with various actions like so:
This works fine, its a little slow in IE (javascript rendering) but it works. However randomly I'll get a stuff up in the display:
notice the gap there, its pushed it out wide, also, its made the rest of the rows squish up. I've tried every CSS/HTML trick I can think of to try and get IE to render it properly, but I'm out of ideas (any suggestions would be great!) . I'm using JQuery Sortable so you can drag each of those rows around, I noticed that when you drag it and place it again, it displays correctly. It's as if it thinks theres an extra TD there, when there isn't.
So I opened the IE developer tools and copied the inner HTML of the HTML element. Pasted this into a HTML file and put it on the server, turned off the JS so it wouldn't reload the elements and ran the page. It displays perfectly, just as in my first image.
So I'm confused as to why IE will render the page fine if the HTML is present from the start, but the templating engine causes odd stuff ups.
I'll probably look at rendering that part of the HTML on the server, and only use the templating where I need to. But has anyone come across this sort of issue before? is there any trick I can do to make it render it as it should?
we had similar problem in our company and our designer solved it. Solution was in concatenating tags one after another without spaces and/or without new line. Code is not looking great after that but still solves problem.
Thanks,
Nikola
I have a page which appears to load fully, but I actually have to wait a further 6-10 seconds for things like buttons to become fully functional.
In IE you can still see the browser loading bar at full for this time after the page displays.
Does anyone know why this might be? I stripped out all the javascript and it still does it.
I get that in my pages sometimes when I don't compress my images. Large image files, or other large media, would be the first place I would check.
Something else I normally look for in speeding up the page is time it takes to download services (feed parsing etc), though since you took out all your javascript that shouldn't be a problem.
The problem with this was the way the page was rendering from the asp:repeater
Instead I created a datagrid and it seemed to eliminate the problem. No idea why as I'd expect it to be the other way around if anything.
Most of javascript and web development books/articles says that you must put CSS in the head tag and javascript at the bottom of the page.
But when I open html source of famous websites such as this one stackoverflow, I find they put some js files in the head tag.
What's Pros and Cons of both approaches and when to use which?
Found another question for the same issue:
Where should I declare JavaScript files used in my page? In <head></head> or near </body>?
From Yahoo's Best Practices for Speeding Up Your Web Site:
The problem caused by scripts is that
they block parallel downloads. The
HTTP/1.1 specification suggests that
browsers download no more than two
components in parallel per hostname.
If you serve your images from multiple
hostnames, you can get more than two
downloads to occur in parallel. While
a script is downloading, however, the
browser won't start any other
downloads, even on different
hostnames.
In some situations it's not easy to
move scripts to the bottom. If, for
example, the script uses
document.write to insert part of the
page's content, it can't be moved
lower in the page. There might also be
scoping issues. In many cases, there
are ways to workaround these
situations.
An alternative suggestion that often
comes up is to use deferred scripts.
The DEFER attribute indicates that the
script does not contain
document.write, and is a clue to
browsers that they can continue
rendering. Unfortunately, Firefox
doesn't support the DEFER attribute.
In Internet Explorer, the script may
be deferred, but not as much as
desired. If a script can be deferred,
it can also be moved to the bottom of
the page. That will make your web
pages load faster.
Therefore, in general, it is preferrable to put them at the bottom. However, it isn't always possible, and it often doesn't make that much of a difference anyway.
As other people have said, when you put javascript in the head it delays the rendering of the page until after the scripts have loaded, which means the page may take longer to load - especially if you are downloading large script files.
If you move your script tags to the end of the page, you will ensure that the browser downloads images and stylesheets before the script tags and the page will likely apear to be rendered before the scripts start to run. This also means that if you are depending on some functionality from your scripts, this will not be available until a bit after the page is visible to the user.
If you are adding styles or elements (etc. switching textfields with some form of richer editor) this will be visible to the user as flickering.
If you are adding click-events to elements, they will not be clickable until a bit after the elements themselves are visible.
Sometimes theses issues requires you to put your scripts in the head, other times you will be fine by sticking them in the bottom.
IMHO (completely against YSlow and lot's of clever people) you should keep your scripts in the head tag, and just rely on them to be cached most of the time.
In general you should place script references at the bottom of your page. Scripts not only need to be downloaded, they must also be evaluated and executed before the block is released and the page proceeds with the rendering process. Things like Modernizr should be placed in the top because it does some feature detections as well as HTML5 shims that you will probably want.
Another reason you want to try to place scripts at the bottom of the page is Single Points of Failure or SPOFs. This is where a script call times out or for some other reason blocks the page execution. This can happen a lot with third party advertising libraries, etc.
Yes you may have to think a little harder about how you architect your application, but I found it to become very natural very quickly for me. I have built hundreds of web apps over the past 4 years with the script at the bottom and I can tell the difference. I may be 500ms it might be 5000ms but it all matters.
It really depends on your website. If you are accessing and invoking the JavaScript functions inside the body then it must be referenced in the header so that is is loaded. Else if you are only going to call the JavaScript when the whole document is loaded then it is wise to put the JavaScript at the end of body. By putting .JS file at the end you load the whole page and then fetch the .JS file. This way the user will be able to quickly see the page and by the time he/she gets familiar with the page the .JS file has already been downloaded.
Any javascript in the head will be evaluated before the page is loaded, meaning the page feels like it takes longer to load. It is slightly harder to get events to work properly if all the javascript is at the end, but jQuery pretty much solves this problem for you.