I need some advice on CSS placements for the sake of website load times
I read that it's best to have 'critical CSS' in the head and the rest can be placed in their respective page's body via the tag.
Is it good practice if I loaded all the CSS or at least the 'Generic' styles that many pages share while I kept page specific styles in a tag in the page's body?
One side question, some of my pages use jQuery, should I only load that at the bottom of those pages or leave it in the template head?
I tried both and the site loads just fine, but I know under the hood results may vary. I'm not sure how to even check. I tried websites that test a website's load performance and I got mixed results. So I'm not sure how to optimize my website's performance.
Usually all CSS files are called in the head, one thing you can do to improve performance is to modularize, let's say that you have the global styles in one file called global.css and it contains your font specs, global components used in all pages such as navbar, footer, layouts, etc... And in another file you can only put the styles regarding your specified page such as contact section that's another page called contact.css and there you can have overrides to global file and specific styles that you only use in this page.
This way you can serve less heavy files regarding the page that user's requiring.
Regarding you jQuery question I suggest that don't load jQuery library if you're not using it, it's useless. Only load it in the pages that you're using the library. Hope it helps!
Related
I am developing a static website (don't need any server-side support. I have Basic HTML and JAVAscript) which have a number of pages.
all pages have the same top menu (header) and footer.
what is the best practice considering SEO?
I have two options :
Option 1. Should I copy header.html & footr.html code on every HTML page?
Option 2. Should I include header.html & footer.html on every HTML page?
which Option is better? Does any of them affect SEO?
if Option 2 is the right solution then my follow up question is "How to include common header.html and footer.html ?" I don't want to use PHP/ iframe.
For easy client end work , I could have suggested jquery or javascript for client end rendering of header and footer, but you are looking for SEO friendly web pages.
Considering SEO you need to have rendered HTML pages with header and footer so crawlers can read it (and above solution won't work for that as it renders extra stuff after page load). So either you go for copying and pasting header footer to each page or use PHP/.NET etc for server end rendering that will handle header and footer while rendering.
How often do you change the content of the header? When I was starting with web design I used to include the whole menu with/copy paste, and then do search/replace across all files. But this was before PHP and JS were around.
Content-wise, it should be the same. There could be a difference in the number of HTTP requests and load time if you are including something from another file.
These are so small speed differences that I don't think that it will make any difference SEO-wise.
I personally like to use PHP to include content but you have said that this is not an option for you. Depending on whether you want to use jquery, pure JS, or some other way there is a bunch of different approaches.
Where is the best place to put Jquery code (or separate Jquery file)? Will pages load faster if I put it in the footer?
Put Scripts at the Bottom
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.
EDIT: Firefox does support the DEFER attribute since version 3.6.
Sources:
http://www.w3schools.com/tags/att_script_defer.asp or better:
http://caniuse.com/#feat=script-defer
All scripts should be loaded last
In just about every case, it's best to place all your script references at the end of the page, just before </body>.
If you are unable to do so due to templating issues and whatnot, decorate your script tags with the defer attribute so that the browser knows to download your scripts after the HTML has been downloaded:
<script src="my.js" type="text/javascript" defer="defer"></script>
Edge cases
There are some edge cases, however, where you may experience page flickering or other artifacts during page load which can usually be solved by simply placing your jQuery script references in the <head> tag without the defer attribute. These cases include jQuery UI and other addons such as jCarousel or Treeview which modify the DOM as part of their functionality.
Further caveats
There are some libraries that must be loaded before the DOM or CSS, such as polyfills. Modernizr is one such library that must be placed in the head tag.
Only load jQuery itself in the head, via CDN of course.
Why? In some scenarios you might include a partial template (e.g. ajax login form snippet) with embedded jQuery dependent code; if jQuery is loaded at page bottom, you get a "$ is not defined" error, nice.
There are ways to workaround this of course (such as not embedding any JS and appending to a load-at-bottom js bundle), but why lose the freedom of lazily loaded js, of being able to place jQuery dependent code anywhere you please? Javascript engine doesn't care where the code lives in the DOM so long as dependencies (like jQuery being loaded) are satisfied.
For your common/shared js files, yes, place them before </body>, but for the exceptions, where it really just makes sense application maintenance-wise to stick a jQuery dependent snippet or file reference right there at that point in the html, do so.
There is no performance hit loading jquery in the head; what browser on the planet does not already have jQuery CDN file in cache?
Much ado about nothing, stick jQuery in the head and let your js freedom reign.
Nimbuz provides a very good explanation of the issue involved, but I think the final answer depends on your page: what's more important for the user to have sooner - scripts or images?
There are some pages that don't make sense without the images, but only have minor, non-essential scripting. In that case it makes sense to put scripts at the bottom, so the user can see the images sooner and start making sense of the page. Other pages rely on scripting to work. In that case it's better to have a working page without images than a non-working page with images, so it makes sense to put scripts at the top.
Another thing to consider is that scripts are typically smaller than images. Of course, this is a generalisation and you have to see whether it applies to your page. If it does then that, to me, is an argument for putting them first as a rule of thumb (ie. unless there's a good reason to do otherwise), because they won't delay images as much as images would delay the scripts. Finally, it's just much easier to have script at the top, because you don't have to worry about whether they're loaded yet when you need to use them.
In summary, I tend to put scripts at the top by default and only consider whether it's worthwhile moving them to the bottom after the page is complete. It's an optimisation - and I don't want to do it prematurely.
Most jquery code executes on document ready, which doesn't happen until the end of the page anyway. Furthermore, page rendering can be delayed by javascript parsing/execution, so it's best practice to put all javascript at the bottom of the page.
Standard practice is to put all of your scripts at the bottom of the page, but I use ASP.NET MVC with a number of jQuery plugins, and I find that it all works better if I put my jQuery scripts in the <head> section of the master page.
In my case, there are artifacts that occur when the page is loaded, if the scripts are at the bottom of the page. I'm using the jQuery TreeView plugin, and if the scripts are not loaded at the beginning, the tree will render without the necessary CSS classes imposed on it by the plugin. So you get this funny-looking mess when the page first loads, followed by the proper rendering of the TreeView. Very bad looking. Putting the jQuery plugins in the <head> section of the master page eliminates this problem.
Although almost all web sites still place Jquery and other javascript on header :D , even check stackoverflow.com .
I also suggest you to put on before end tag of body. You can check loading time after placing on either places. Script tag will pause your webpage to load further.
and after placing javascript on footer, you may get unusual looks of your webpage until it loads javascript, so place css on your header section.
For me jQuery is a little bit special. Maybe an exception to the norm. There are so many other scripts that rely on it, so its quite important that it loads early so the other scripts that come later will work as intended. As someone else pointed out even this page loads jQuery in the head section.
Just before </body> is the best place according to Yahoo Developer Network's Best Practices for Speeding Up Your Web Site this link, it makes sense.
The best thing to do is to test by yourself.
On a website, I'm experiencing a "flash" of white that occurs between page loads. It looks bad because I'm using a background image and when the page loads, the background images flash before it comes onto the screen (take a look for yourself). This issues occurs in chrome and IE but not in firefox.
The site has a way of preloading stuff. Every element on the page is in a div wrapper #website which is initially at display:none, and every image is in a div wrapper #website-images which is also hidden. Then the site (using a jquery plugin) checks to see if all the images in #website-images are done loading, once they are a cookie is set to remember that this user has loaded the images already so it won't go through the preloading process once they go to another page or reload the current one, then a call to $("#website").show() is made to display the webpage.
So what could be causing this flickering between the page loads? Is it my way of preloading images? I've added different doctypes, and changed meta information but NOTHING has worked. I'm really lost here, does anyone have any ideas or insights?
This is happening because the DOMLoaded event is fired enough milliseconds before the page actually renders.
In a nutshell, this means you have to optimise your website's speed. This doesn't mean to make it download faster, but it means to download in the correct order, in a non-blocking way.
Step one: Your markup
1)
It seems there is a lot you can do to optimise your markup. Firstly, the order of stylesheets and JavaScripts can be optimised. To ensure CSS files are downloaded asynchronously, you always have to include external CSS before external JavaScript files. style.css is downloaded after some/all of your JavaScript calls.
There is 1 script block found in the head between an external CSS file and another resource. To allow parallel downloading, move the inline script before the external CSS file, or after the next resource.
2)
Your main JavaScript file is inline within your markup. Not only does this block the page download until the script has finished downloading, but having it before your content is probably causing (or adding to) the white flash.
Loading your script asynchronously in the head is my preferred method. You will then have to trigger your script when the DOM has finished loading, or you can achieve the same result by placing the script at the bottom of the body tag.
Step two: Harness the browser's capabilities
1) Looking at the http headers, there are 28 items being served as separate HTTP calls, that are not being cached on the browser (including the html pages, jpg images, stylesheets and JavaScript files).
These items are explicitly non-cacheable, and this can be easily fixed by editing your webserver's configuration.
2) Enable gzip compression. Most web browsers (yes, even IE) supports gzip decompression, and most (if not all) web servers support compressing using gzip. You could even go overkill and look into SPDY, which is an alternative lighter HTTP protocol (supported in Chrome and Firefox).
Step three: Content serving
There are around 30 individual items being served from your domain. Firstly, consider how you could reduce this number of requests. 30 HTTP requests per page view is a lot. You can combat this using the following methods:
1) Paralleled downloads across multiple hostnames. Browsers currently limit the number of concurrent connections to a single domain. Serving your images from a separate domain (for example, img.bigtim.ca) can allow them to be served in parallel to other content.
2) Combine multiple items into one. Many items that are downloaded are purely style content, such as the logo, menu elements, etc. These can be combined into a single image (downloaded only once), and split using CSS. This is called CSS spriting. Stack Overflow does this: look here.
3) If you cannot reduce the amount of items needing downloading, you could reduce the load on your server (and in turn, the client's browser) by serving static content from a cookieless domain. Stack Overflow does this with all their static content such as images, stylesheets and scripts.
Step four: Optimise your own code
There's only so much that HTTP and browser technology can do to help your website's speed. This last step is down to you.
1) Is there any reason you choose to host jquery yourself? Jquery's download page shows multiple CDNs where you can point to for speedy, cached script downloading.
2) There are currently over 20 unused CSS rules within your stylesheets (that's 36% of your entire CSS file). Have a re-think of what is really needed.
3) The main chunk of JavaScript (at the top of your body tag) seems to be a hack to attempt to speed things up, but is probably not helping anything.
A cookie is being set to specify whether or not the page has faded in yet. Not only are you using JavaScript to perform a transition which can happily be performed by CSS, but more than half of the script is used to define the functionality for reading and writing the cookie.
Seeing things like this: $("body").css ("background-image", "url('images/background.png')"); and $("#website").show (); usually gets me ranting about "separation of concerns", but this answer is long enough now so hopefully you can see that it is bad practice to mix style and functionality in the same code.
Addendum: Looking at the code, there is no need for jquery at all to
perform what you are doing. But then again, there is no need to
perform what you are doing, so you could probably do better without any
JavaScript at all.
Move your javascript to the end of the html just before closing the body tags. Sometimes it helps.
I know this is old thread but here is a hack I tried and works.
The idea is not to display anything while CSS is loaded completely.
in html file:
<body style="display:none">
in your CSS, the last line:
body{display:block !important}
CSS is render-blocking.
Divide you CSS into 2 parts -
Critical CSS
Non-Critical CSS
Make Critical CSS load with the page. It should come embedded within the head tag.
Make Non-critical CSS lazy load via ajax.
This will result in serious performance optimization in your webpage leading to less white-screen time.
Also, you can consider loading your Javascript in async/defer way.
This type question has been asked a number of times, but I can't find a solution that fits exactly what I am looking for..
I have a large App based in Ajax. Ajax responses includes HTML and JavaScript files used to build pages, widgets and so on.
I would like to load the CSS for these widgets on the fly via the ajax JavaScript calls. There can be any number of CSS files loaded dynamically as and when required. The most commonly accepted way (from what I can see) is to place an id on the link tag and target that, but as i am including an undetermined number of external style sheets, this will not work..
Any suggestions on how to solve this problem would be appreciated..
I am using Dojo to power the app, if that it of any help..
Thanks
We load as well many widgets on the fly in our app.
Each widget is an HTML + JS + CSS that is loaded with an IFRAME.
Once the IFRAME is loaded, you can loop on the LINK in the HEAD and import them in the main page.The same apply for the HTML, in our case it is a set of pure.js templates.
The JS extend automatically at load time a global object in the main page.
Be careful about dynamically loading CSS. CSS is loaded asynchronously so you can get race conditions with widgets that do layout in Javascript such as BorderContainer.
You can put all your necessary CSS in a file with import statements. For example, from claro.css
#import url("../dijit.css");
#import url("../../icons/commonIcons.css");
#import url("Common.css");
...
and then use the build tool to compact everything for production.
Hiho,
There's an existing website that i need to include into another site which goes like this:
a.mysite.com
and i need to fetch content from this site in my
www.mysite.com
website...
As i need to access the content of the iframe the Same origin policy produces a problem here.
What i did was to configure mod_proxy on Apache to proxy pass all requests from
www.mysite.com/a
to
a.mysite.com
This will work fine...but my problem is that im not sure what the best way would be to include those pages.
1. Idea
As the content of the iframe is a full featured site with a top navigation...left navigation etc....i would need to change the page template to only show the content box to be able to integrate that page in the iframe.
2. Idea
I could just load the DIV where the content lies through JQuery.load() and integrate it into my site.
What is the best way to accomplish such a task? How bad is both ideas from the SEO point of view?
Unless it involves significant rework, the best solution is to combine the two into a single HTML page on the server side (using server-side includes).
Advantages:
No problems with SEO as it's delivered as a single page. Content in iFrames and content loaded via AJAX (with an associated link in the HTML) are traversed, but only the link, not the content itself is associated with the main page. See: http://www.straightupsearch.com/search-marketing/best-practices/seo_iframes_a_g/
Faster page load - either of your suggestions will cause the main page to be loaded first before the other content is loaded.
No reliance on Javascript - your second method will fail completely if javascript is not supported / turned on.
Include all JS and CSS only once - your first method will require these to be duplicated in the <head> of each page. This is more of a long term advantage if you wish to achieve full integration of site "a". However, it can be a disadvantage initially, see below.
Disadvantage:
May cause conflicts with scripts and CSS between the two pages. However, this same problem exists with your second method.
If you must choose between either of the two options you proposed, I would not select the second as others have suggested. Significant amounts of static content should never be loaded via Ajax, and in this scenario gives you no additional benefits. At least iFrames guarantee no JS and CSS conflicts.
Use the 2nd approach (jQuery.load) and if you're working with HTML5, for browsers that support the History API you can change the URL to whatever the content is for that div.
Check out https://github.com/blog/760-the-tree-slider for an example of how github did it for their tree slider.
EDIT:
I am not sure how using an iFrame whose src points to your own domain affects search rankings but at best it's a grey area. I would assume that possibly some pagerank would trickle from the parent to the child but I have no clue how it would work for instance if a blogger linked to your page with the iframe that pointed to another page. This would be a pretty good question to ask at the Webmaster Help Forum
Always say no to iframes. jQuery+Ajax all the way.