I'm trying to optimize the page load time of a website. Now I've implemented almost all suggestion Google PageSpeed Insights gave me. However it keeps suggesting using a non-blocking stylesheet so that the above-the-fold content can be rendered before loading the stylesheet (using inline CSS):
Eliminate render-blocking JavaScript and CSS in above-the-fold content.
Your page has X blocking CSS resources. This causes a delay in rendering your page.
Approximately Y% of the above-the-fold content on your page could be
rendered without waiting for the following resources to load. Try to
defer or asynchronously load blocking resources, or inline the
critical portions of those resources directly in the HTML.
It refers to the following information on how it should be done. Basically:
<html>
<head>
<style>
.blue{color:blue;}
</style>
</head>
<body>
<div class="blue">
Hello, world!
</div>
</body>
</html>
<link rel="stylesheet" href="small.css">
Although I have never seen a link to a stylesheet tag outside off the HTML tag, I changed my website using this strategy.
However, the online version of Google PageSpeed insights still complains about the stylesheet. Even more strange, the similar browser plugin (PageSpeed Insights for Chrome) says the exact opposite thing:
When you remove inline style blocks and elements from the main text of the document and put it in the header, the display performance will be improved.
Now my questions are:
Which one is correct? (In perspective of SEO and ofcourse in the perspective of UX)
Is there another way which keeps them both pleased? (HTML5 and JavaScript solutions are accepted if they are cross-browser and do improve page load time)
I would suggest you to prioritizing on getting the highest possible score of the online PageSpeed Insights if possible get it 100/100 like shown below. It will engage your page in the Google search ranking since the page speed score is one of the SEO factor as explained here.
No other solution to this unless finding out which part of your CSS is used for the above-the-fold initial view of your page. Once you know this you should inline this CSS in your HTML header and lazy load the rest of your CSS.
You could find then whatever solution to minimize the effect as long as the score as well as the validation of every important aspect e.g. html5 and css are maintained.
]
Google wants you to load the "Above the fold" content as fast as you can, for that you can create a separate stylesheet giving it the basic structure coding like width and all that. You can also try to remove any heavy image in that area and if you cannot then try to reduce the size of those images.
Then you can create a second stylesheet to load after the first one loads and you can get that error removed about the css.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How bad is it to embed JavaScript into the body of HTML?
Ok, so I've been using JavaScript for a good while now and I'm no stranger to it, but my question is in regards to where the JavaScript should actually be placed in a HTML file.
I've always been told and worked under the impression that all of your references to external script files should be contained in the head tag and any script that is contained in the current HTML file should be at the end of the file.
Now, more recently and having discussions with co-workers I have seen more and more people placing script blocks in seemingly random places throughout the HTML page, such as
<div>
<p>Foo</p>
<script type="text/javascript">
//some script
</script>
<p>Bar</p>
</div>
Now is this good practice? I've always thought that it wasn't. If so, is it beneficial because the script gets executed at that point, but then why can't you wait until the rest of the HTML has been loaded?
+1 vote for at the bottom of the page
give visitors the;
content and markup first
then display with css
then ui with javascript
appreciate this is a tad high brow
Scripts should be placed at the bottom of the page, as that will allow all of the sites resources, such as images, to download in parallel. Once finished the scripts will then be downloaded, one at a time.
The reason it's better to place scripts at the bottom of the page, is because they block parallel downloads. Normally the browser downloads resources such as images in parallel, two resources at a time (as specified by the HTTP 1.1 specification), per hostname. Scripts stop this from happening and will not allow anything else to download until after they have been fully downloaded.
Duplicate of this Question
Is it bad practice to embed JavaScript into the body of HTML?
It is helpful (and perfectly valid) sometimes when you want to ensure that certain dom is created before the script is run.
When I use inline, It has an obvious benefit, for me. for example.
(I will try to explain it with basic scenario. so don't be critical about the scenario)
I have A,B and C html sections (divs) in my page. obviously I will render them all, but I want only one section visible at a time to a visitor. so I can't wait for the whole page and javascript files to be loaded and then apply the "set visibility priority for section" javascript method to fire. because in the meanwhile all three sections (A,B and C) will remain visible until everything is not fully loaded. and the page might look awful so I prefer to use inline javascript.
Started to write a comment underneath Rob Sedge's reply, but it grew larger...
1) CSS at top, in the header (unless you want the user to see page without styling, for large HTML files / external JS, where loading times can be extensive)
2) Content and markup in the body
3) JS in the footer, before </body>
Even though currently JS evaluation is strongly suggested to occur within $(document).ready, or $(window).load events, some external scripts might not do that - in such case they will be evaluated as soon as the content has been downloaded, often causing a random behavior. Furthermore , content is evaluated as soon as browser actually processes given tag (point 1), thus additional fun stuff.
An additional (and at least for me main) point is this - let's say that you've got a templating engine, or PHP inclusion in your documents. Now - let's say that you've got a lot of such files, and in one of them JS code needs to be changed. In such cases, if you're not the only person working on a project, you'd need to search for given bit of code in all of those files. Thus - keeping JS in one place is good practice.
Let's add to that, that if you indeed keep your JS code in one place, then such content can be minified or cached, allowing for faster loading of the site overall. Why indeed you'd want the user to download your bit of JS every time the page is loaded, when that script can be evaluated from the cache. If you separate your scripts, such approach becomes hard.
Basically, the scripts that you put on the header, are downloaded synchronously, and you can be sure that they ar going to be executed in order, but if don't need those scripts to be executed before the page finishes loading, maybe you prefeer to include them at the bottom, or in a deferred way, to finish render the page more quickly, and give the users a better experience.
About the scripts contained in the HTML, it depends on what they do. For example, if for some reason you need to do a Document.write, or you want to execute some code before the page is rendered, to modify the DOM, they are very handy.
I strongly recomend you to read the two books of Steve Souders: "High Performance Web Sites" and "Even Faster Web Sites", there you have a very good explanation on the differences.
I have a website that has some intense graphics, and people with slow connections might require download time. While their browser is downloading, they have form options. And a lot of times they will fill the form out and hit submit.
This causes an event validation issue, because the page wasn't fully loaded. I can think of a lot of ways off the top of my head to fix this. I could go back and disable every single control, and then write javascript to enable these controls clientside when the page is loaded.
I also looked into blockui, but it will block the whole page or just a div. I am looking for something I can stick in my masterpage and forget about it.
Any ideas?
It seems like the correct approach would be to load in your intense graphics after-the-fact, so that users can still submit forms as soon as the critical DOM elements are rendered. (I'm assuming it's not vitally important that all the images be loaded before the form gets submitted?)
You could do this fairly easily by causing your images to be loaded as CSS-based backgrounds on div and body elements, based on a specific class, like this:
body.loaded {background: black url("http://us.battle.net/sc2/static/images/layout/body-bg-baked.jpg") center top no-repeat;}
Then have the following code to add that class after the page loads:
$(window).load(function() {$('body').addClass('loaded');});
It shouldn't produce any significant slow-down in the loading of the images, but it will allow all your page's DOM elements and javascript to run while those images are downloading if necessary.
(jsFiddle example)
I couldn't explain the answer myself. But I think this has the gist of what you need to do.
http://www.telerik.com/community/forums/aspnet/ajax/disable-or-gray-out-page-when-displaying-loading-panel.aspx
Okay, so first some background info: I am trying to embed a webpage within another page. The sub-page is basically a small web application written in javascript and html that takes in several screens of input (radio buttons, text boxes, etc.) and gives a screen with results at the end. Each of these screens can be a different size.
There are two methods I have tried using to do the embedding:
1) Copy all of the html and javascript from the sub-page into the main page and stick it in a div/table/whatever.
2) Keep the sub-page in its own file and embed it using embed/object/iframe.
Using the first method the page behaves as it should; the only real problem (aside from being kind of a messy solution) is that the sub-page I am embedding is actually generated by an external application, and every so often the page is replaced with a newer version. This more or less rules out using the first method as a long-term solution.
Now the second method has its own problems. Since the embedded javascript page changes in height, the frame that is holding it needs to vary in size with it. I'm able to change the size using any of the solutions given here, however these do not update the size of the frame as the user progresses through each screen.
The closest solution I've been able to come up with so far is using a document.onclick handler to catch any clicking which might cause the next screen of the sub-page to come along. The handler pauses for a very short time (to allow the next screen to come up) and then calls the necessary resizing function. However this feels like a very hacky solution, and there is also a slightly noticeable delay during with the scroll bar shows up on the side of the frame when it hasn't expanded yet to fit the new content. I'm thinking there must be a better way to do this.
If the file is on the same server/domain, you could just load it in with jQuery. Here is some jQuery code:
<script type="text/javascript">
$(document).ready(function() {
$('#id-of-div').load('/path/to/page.html');
});
</script>
Just change id-of-div to the id of the div that you want the page to be loaded into and change /path/to/page.html to the actual URL to the page. (you don't need the domain of it, just the path to it)
I hope this helps.
If this answers your question, please remember to click the checkmark next to this to accept this answer.
I hate how you can actually see webpages load. I think it'd be much more appealing to wait until the page is fully loaded and ready to be displayed, including all scripts and images, and then have the browser display it. So I have two questions:
How can I do this?
Is this common practice? If not, why?
This is a very bad idea for all of the reasons given, and more. That said, here's how you do it using jQuery:
<body>
<div id="msg" style="font-size:largest;">
<!-- you can set whatever style you want on this -->
Loading, please wait...
</div>
<div id="body" style="display:none;">
<!-- everything else -->
</div>
<script type="text/javascript">
$(document).ready(function() {
$('#body').show();
$('#msg').hide();
});
</script>
</body>
If the user has JavaScript disabled, they never see the page. If the page never finishes loading, they never see the page. If the page takes too long to load, they may assume something went wrong and just go elsewhere instead of *please wait...*ing.
I think this is a really bad idea. Users like to see progress, plain and simple. Keeping the page at one state for a few seconds and then instantly displaying the loaded page will make the user feel like nothing is happening and you are likely to lose visits.
One option is to show a loading status on your page while stuff processes in the background, but this is normally reserved for when the site is actually doing processing on user input.
http://www.webdeveloper.com/forum/showthread.php?t=180958
The bottom line, you at least need to show some visual activity while the page is loading, and I think having the page load in little pieces at a time is not all that bad (assuming you aren't doing something that seriously slows down page load time).
There is certainly a valid use for this. One is to prevent people from clicking on links/causing JavaScript events to occur until all the page elements and JavaScript have loaded.
In IE, you could use page transitions which mean the page doesn't display until it's fully loaded:
<meta http-equiv="Page-Enter" content="blendTrans(Duration=.01)" />
<meta http-equiv="Page-Exit" content="blendTrans(Duration=.01)" />
Notice the short duration. It's just enough to make sure the page doesn't display until it's fully loaded.
In FireFox and other browsers, the solution I've used is to create a DIV that is the size of the page and white, then at the very end of the page put in JavaScript that hides it. Another way would be to use jQuery and hide it as well. Not as painless as the IE solution but both work well.
Here's a solution using jQuery:
<script type="text/javascript">
$('#container').css('opacity', 0);
$(window).load(function() {
$('#container').css('opacity', 1);
});
</script>
I put this script just after my </body> tag. Just replace "#container" with a selector for the DOM element(s) you want to hide. I tried several variations of this (including .hide()/.show(), and .fadeOut()/.fadeIn()), and just setting the opacity seems to have the fewest ill effects (flicker, changing page height, etc.). You can also replace css('opacity', 0) with fadeTo(100, 1) for a smoother transition. (No, fadeIn() won't work, at least not under jQuery 1.3.2.)
Now the caveats: I implemented the above because I'm using TypeKit and there's an annoying flicker when you refresh the page and the fonts take a few hundred milliseconds to load. So I don't want any text to appear on the screen until TypeKit has loaded. But obviously you're in big trouble if you use the code above and something on your page fails to load. There are two obvious ways that it could be improved:
A maximum time limit (say, 1 second) after which everything appears whether the page is loaded or not
Some kind of loading indicator (say, something from http://www.ajaxload.info/)
I won't bother implementing the loading indicator here, but the time limit is easy. Just add this to the script above:
$(document).ready(function() {
setTimeout('$("#container").css("opacity", 1)', 1000);
});
So now, worst-case scenario, your page will take an extra second to appear.
Immediately following your <body> tag add something like this...
<style> body {opacity:0;}</style>
And for the very first thing in your <head> add something like...
<script>
window.onload = function() {setTimeout(function(){document.body.style.opacity="100";},500);};
</script>
As far as this being good practice or bad depends on your visitors, and the time the wait takes.
The question that is stil left open and I am not seeing any answers here is how to be sure the page has stabilized. For example if you are loading fonts the page may reflow a bit until all the fonts are loaded and displayed. I would like to know if there is an event that tells me the page is done rendering.
Also make sure the server buffers the page and does not immediately (while building) stream it to the client browser.
Since you have not specified your technology stack:
PHP: look into ob_start
ASP.NET: make sure Response.BufferOutput = True (it is by default)
obligatory: "use jQuery"
I've seen pages that put a black or white div that covers everything on top of the page, then remove it on the document.load event. Or you could use .ready in jQuery That being said, it was one of the most anoying web pages I've ever seen, I would advise against it.
in PHP-Fusion Open Source CMS, http://www.php-fusion.co.uk, we do it this way at core -
<?php
ob_start();
// Your PHP codes here
?>
YOUR HTML HERE
<?php
$html_output = ob_get_contents();
ob_end_clean();
echo $html_output;
?>
You won't be able to see anything loading one by one. The only loader will be your browser tab spinner, and it just displays everything in an instant after everything is loaded. Give it a try.
This method is fully compliant in html files.
You can hide everything using some css:
#some_div
{
display: none;
}
and then in javascript assign a function to document.onload to remove that div.
jQuery makes things like this very easy.
In addition to Trevor Burnham's answer if you want to deal with disabled javascript and defer css loading
HTML5
<html class="no-js">
<head>...</head>
<body>
<header>...</header>
<main>...</main>
<footer>...</footer>
</body>
</html>
CSS
//at the beginning of the page
.js main, .js footer{
opacity:0;
}
JAVASCRIPT
//at the beginning of the page before loading jquery
var h = document.querySelector("html");
h.className += ' ' + 'js';
h.className = h.className.replace(
new RegExp('( |^)' + 'no-js' + '( |$)', 'g'), ' ').trim();
JQUERY
//somewhere at the end of the page after loading jquery
$(window).load(function() {
$('main').css('opacity',1);
$('footer').css('opacity',1);
});
RESOURCES
CSS delivery optimization: How to defer css loading?
What is the purpose of the HTML "no-js" class?
How to get the <html> tag HTML with JavaScript / jQuery?
How to add/remove a class in JavaScript?
While I agree with the others that you should not want it I'll just briefly explain what you can do to make a small difference without going all the way and actually blocking content that is already there -- maybe this will be enough to keep both you and your visitors happy.
The browser starts loading a page and will process externally located css and js later, especially if the place the css/js is linked is at the 'correct' place. (I think the advice is to load js as late as possible, and to use external css that you load in the header). Now if you have some portion of your css and/or js that you would like to be applied as soon as possible simply include that in the page itself. This will be against the advice of performance tools like YSlow but it probably will increase the change of your page showing up like you want it to be shown. Use this only when really needed!
You could start by having your site's main index page contain only a message saying "Loading". From here you could use ajax to fetch the contents of your next page and embed it into the current one, on completion removing the "Loading" message.
You might be able to get away with just including a loading message container at the top of your page which is 100% width/height and then removing the said div on load complete.
The latter may not work perfectly in both situations and will depends on how the browser renders content.
I'm not entirely sure if its a good idea. For simple static sites I would say not. However, I have seen a lot of heavy javascript sites lately from design companies that use complex animation and are one page. These sites use a loading message to wait for all scripts/html/css to be loaded so that the page functions as expected.
Don't use display:none. If you do, you will see images resize/reposition when you do the show(). Use visibility:hidden instead and it will lay everything out correctly, but it just won't be visible until you tell it to.
Hope this code will help
<html>
<head>
<style type="text/css">
.js #flash {display: none;}
</style>
<script type="text/javascript">
document.documentElement.className = 'js';
</script>
</head>
<body>
<!-- the rest of your code goes here -->
<script type="text/javascript" src="/scripts/jquery.js"></script>
<script type="text/javascript">
// Stuff to do as soon as the body finishes loading.
// No need for $(document).ready() here.
</script>
</body>
</html>
Put text at the top of the page. While the user reads it, the rest of the page can load and it will be ready by the time the user scrolls down.
I am, frankly, a bit disturbed at many of the answers here. I'd say all of them are terrible. Although I share the skeptical reaction of the various top respondents, many answers give "solutions" that won't display anything at all to a user who has JavaScript disabled, and many others rely on a customized on-page loading notice, while signaling to the browser that the page is already loaded.
As a user, I hate both of these outcomes, so as a web-developer, I'd say these are both "non-solutions". You never want to anger your userbase and the solutions given here will anger a lot of users. I especially hate these approaches because if the user opens a webpage in the background in a new tab, the browser will display the page as loaded but the user might click over to it to find that it isn't loaded.
Independently of your question here, best practice is to make as much of your site work without JavaScript as possible, and best practice is to use the browser's built-in loading signals and never signal to the browser that the page is loaded before it actually is. So really, the only good way to do this is to make your page load so fast that there is never any moment of the user waiting.
The best way to achieve what you want is avoid use of Javascript to load elements of the page, and then optimize the page intensely. Here are the components of this approach:
Have JavaScript on the page if you like, but don't use it to load or otherwise modify any DOM elements after the initial request is fulfilled by the server. Use JavaScript to modify elements of the page only later, such as if triggered by user input, or perhaps to refresh an element after some time, but not in any way related to the page's initial loading. I.e. use JavaScript for what it was designed for (to make webpages interactive) and don't use it to do what HTML was designed for (to make the webpage in the first place.)
Avoid the use of any heavy JavaScript libraries and include as little JavaScript as possible. Never include JavaScript files generically, i.e. only include specific files / libraries in specific pages where you need them.
Specify the width and height of any images in the page code itself, so that the browser can know the exact layout before the image loaded. This reduces any "choppiness" as the page loads, i.e. elements moving around as the browser resizes the boxes in which images of unspecified width are contained.
Ensure that image files are in the exact dimensions being displayed on the page and are not being downsized by the browser. This minimizes file size and also minimizes CPU work the user's computer needs to do to resize images, both of which can affect load time.
Optimize the compression of images, which includes using a good lossy format like JPG and lowering the compression level to as low as you can go without affecting perception. Use lossless formats like PNG only where necessary and ideally keep them small in dimension so the filesize is also small.
Focus the intensity of your optimization efforts on any elements that load "above the fold" on a typical page, as these are what is going to affect what the user sees. Users rarely scroll down instantly, so if elements lower down on the page load a bit slower, almost no one will notice. But still optimize these lower elements reasonably because they also affect server load, bandwidth, and user CPU load.
If you use any elements at all in your page that are potentially very slow to load due to reasons beyond your control, such as content pulled from another server (ads, social media widgets, integrations with other websites, etc.), compartmentalize these in an element of fixed size, and ideally place it below the fold.
Avoid auto-ads, page-modifying AI (like Ezoic), or any other external add-ins that necessarily breaks or undermines one or more of these recommendations. For example, auto-ads are terrible because they rely on loading an external resource,they usually have heavy javascript libraries, and they also modify the page layout. Even the best-designed auto-ads are going to completely undermine all your other optimization efforts.
If you are running a company with multiple developers, quickly jettison any developers who are not fully committed to a lightweight, fast-loading web design. Ideally, don't ever hire such people to begin with. A lot of people get really vested in a certain philosophy or style of development that is at odds with lightweight design. The world would be a better place if these people were in a different line of work, rather than designing webpages.
So you've optimized your page.
This produces the outcome that, if the user clicks the link directly, they'll see the content above the fold fully loaded immediately or nearly-immediately, worst-case-scenario being that a couple images fill in in a second or two. By the time they scroll down, everything else will already be loaded. Any truly-slow-to-load content, such as Google Analytics tracking or other third-party services, will not be central to the appearance of the webpage itself, so the user will see a fully-loaded page even if there are still a few invisible elements loading behind the scenes.
On the other hand, if the user loads the link in a background tab, it will display as loading to the browser, showing the animated symbol in the tab, until it is truly fully loaded. Once it displays as loaded in the tab, if they click it, it will be fully loaded.
In addition, you will have made the page load really fast, which is a good thing in and of itself.
This is a win-win. The user sees a full-loaded page nearly instantly, there is almost never any waiting while looking at a half-displayed page, the loading symbol works as expected when loading a tab in the background, and on top of this you've netted a ton of side-benefits like reduced bandwidth and server CPU load, not to mention lessening the load on the user's CPU as well. (Many users HATE when your page cranks their CPU, and rightfully so.)
So yeah, your choice what to do, but there is only one real solution here and it is lightweight, efficient web design.