it's not the first time that I'm restyilin' my website and there's always this problem: when I analyze the page with the Google PageSpeed, it suggests me to put the Jquery and a few other .js codes at the bottom of the page to increase the loading speed.
The problem is that most of the time when I do that the slider, in this specific case, do not work.
Is there an easy solution for this?
I already minified and included the jquery on my wesbite as (jqu.js)
It's not always the case that jQuery can be loaded in the footer of the page. PageSpeed Insights does not catch the cases when this occurs, and thus will always give you a penalty. I'm familiar with this happening with various Carousel-type Javascript UI elements; it sounds like your slider is affected too.
Related
I would like to use Scratchblocks (a tool for rendering visual Scratch code blocks from a text listing, on GitHub) on my Squarespace website. The problem I am getting is that the scratchblocks are never rendered on the first load - but only after a refresh.
This is in the header (set in the header for that particular blog):
<script src="https://scratchblocks.github.io/js/scratchblocks-v3.1-min.js""></script>
Then I think I need to call this function at the end of the page - I've put it in the footer:
scratchblocks.renderMatching('pre.blocks');
NOTE: When I view the source I sort of see this JavaScript twice at the end of the page. Not sure what is happening there.
Here's an example of it on my website, where it renders the scratchblocks only after a refresh. [UPDATE - following the fix provided below, this now renders first time, every time as far as I can tell.]
[http://www.glennbroadway.com/coding-zone/2017/4/6/simple-collisions-in-scratch]2
Here's an example of someone else using it and it working properly. I've inspected the source and I can't work out how they are doing it.
https://codeclubprojects.org/en-GB/scratch/memory/
I've also tried all the different methods listed elsewhere on stackoverflow for getting javascript to load only after the HTML has finished. I can't get any of them to work - but I think the problem is something to do with Squarespace, I just don't have the knowledge to work out what.
Any help would be greatly appreciated.
In Squarespace, when your custom Javascript only works after a page refresh, it most likely has to do with Squarespace's AJAX loading:
Occasionally, Ajax may conflict with embedded custom code or anchor
links. Ajax can also interfere with site analytics, logging hits on
the first page only.
You may be able to disable AJAX for your template. Or, see the other approaches outlined here: https://stackoverflow.com/a/42604055/5338581 including:
window.addEventListener("mercury:load", function(){
// do stuff
});
In addition, I would generally recommend placing custom code in the "Footer" code injection area unless you have a specific reason to do otherwise.
This is the screenshot of my html page. this commented area is my issue.
Your problem starts with a couple of error's :)
Your Javascript crashes because it looks for a function that doesn't exist "$(...).fancybox()". This means that either you didn't include the fancybox library or that the file where you call in the function fancybox is loaded before the fancybox library is loaded in.
Next problem is that the images that are used in your slider (I assume). Do no longer exist. Try clicking them in the console to see if you can access them in the browser.
Last but not least. You tagged your question as "java". Javascript and java are not the same thing. Your problem involves javascript. Might want to change that tag next time so you can get anwsered faster.
I Hope this helped a bit :)
Good luck!
I've published a website and every page has an or element with Cufon (cufon-yui.js) and sometimes while the page is loading , the visitor can see the text replacement tool doing it's job. It looks bad, some users are asking about it.
Why would that be happening if I'm using it (cufon) like anybody else and I don't' see this text rendering issue happening in most sites.
Also, there's an issue happening as well, with the Hyperlinks that are using Cufon.
Sometimes the cursor (a hand that appears for hyperlinks) disappear , it's bizarre.
Adding the following to your css should solve the issue:
.cufon-loading {
visibility: hidden;
}
use one of the google web fonts or typeface/
I've just started looking at Cufon, so I'm not sure I'm qualified to give an opinion, but I've read the IE has (or had) rendering issues and that you needed to add <script type="text/javascript">Cufon.now();</script> to the end of your body (right before the </body>. If you are running any other heavy scripts on the page, you might want to put them as low on the page as possible and place the Cufon.now() right above those scripts (place Cufon higher in priority). If that doesn't work, try hiding your Cufon elements with JS as soon as the DOM has loaded (visibility:hidden) and then unhide them when the onload event fires (though I'm not sure that's much better than the text flickering).
Use something better?: http://reisio.com/examples/webfonts/
(if you worry about distribution legality, replace your fonts with any of the numerous free clones available all over the internet)
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.
We are developing large ASP.NET applications with lot of dynmically created pages containing ASCX controls. We use a lot of jQuery everywhere.
I have been reading that it would make sense to move the inline JavaScript code to the bottom of the page as it could delay the loading of the page when it's included "too early".
My question is now: Does this still make sense when working with jQuery?
Most of the code is executed in the ready handler, so I would expect that is does not slow down the loading of the page.
In my case the multiple Usercontrols ASCX have all their own jQuery bits and pieces, and it would not be easy to move that all down in the rendered page.
Placing scripts late in the HTML is recommended because loading and executing scripts happens sequentially (one script at a time) and completely blocks the loading and parsing of images and CSS files meanwhile.
Large/lagged/slow-running scripts near the top of the page can cause unnecessary delay to the loading and rendering of the page content/layout.
Script's size (download time) and complexity (execution time (dom traversal, etc.)) factor in - but more importantly, the number of individual <script> HTTP requests matters far more (the fewer requests the better).
Using the "document.ready" handler lessens the delay caused by slow execution - but still leaves the problem of the sequential HTTP overhead.
Recommended reading: High Performance Web Sites by Nate Koeckley.
You could model the different ways of ordering the JavaScript in Cuzillion to see how it affects page loading.
See the examples and this blog post for examples of how ordering of page elements can affect speed.
When you include JS then the loading of the page from that point will defer because of that the JS file might contain a "document.write" statement.
This means that the entire page will STOP being rendered from the point where you include your JS files and make the browser go "white" or something (at least not display the rest of the page) so the short answer is definitely yes...!
(Longer answer is "probably" with 99% probability)
As in move the inclusion of JS (and also inline JS - which you shouldn't use BTW) to the bottom...
When that's said if you're on ASP.NET you shouldn't use jQuery but rather Ra-Ajax which BTW have all these "best practices" automagically included for you...
Most of the time, the reason to move your JavaScript to the bottom of the page is to ensure that any DOM elements the JavaScript might reference have been created before the JavaScript is run. This also ensures that the page has time to render before running any JavaScript.
In this case, I wouldn't worry about moving the JavaScript down lower on the page.