Secure connections rely on all the content in a page being loaded over another secure connection. You can use protocol relative URLs, which will copy the protocol of the parent, or specify for all requests to be secure.
… src="http://cdn.jsdelivr.net/gh/jquery/jquery@3/dist/jquery.min.js" …
… src="//cdn.jsdelivr.net/gh/jquery/jquery@3/dist/jquery.min.js" …
… src="https://cdn.jsdelivr.net/gh/jquery/jquery@3/dist/jquery.min.js" …
JavaScript not only has to be loaded before the page continues loading, but typically has to be executed before continuing as well. This can create massive waits, especially in pages with multiple libraries placed in the header. While a favorite recommendation has always been "move scripts to the footer", this means any external resources do not start downloading in parallel with the page.
Google Analytics, among others, solves this problem by placing a small inline script that then creates a script element that is downloaded without blocking the page. The small inline script itself does, of course, but is generally of little consequence.
While this continues to be used for single, stand-alone scripts, i.e. those with no dependencies, it does not function well with the larger libraries you page may rely on. For instance, using either the async or defer properties in conjuntion with your jQuery will cause an error if later scripts run before it is finished loading. These errors look something like $ is not defined or jquery is not defined.
The issue arises from the fact that any inline or external scripts are run once loaded, whereas async or defer are only run once loaded or the whole page is ready, and there is no guarantee with any use of these that they will be run in order (defer is supposed to, but has several cases where it does not).
What we need then, with jQuery especially, is a way to start loading it early on, in the head preferably, and then "catch" any scripts that try to execute using jQuery functions, and hold them until it is ready. Then it should execute them in order, as it otherwise would have.
…
<script>
$('footer').css('background', 'black');
</script>
</head>
…
…
<script src="jquery.min.js"></script>
</body>
…
…
<script src="jquery.min.js"></script>
<script>$('footer').css('background', 'black');</script>
</head>
…
…
<script src="jquery.min.js"></script>
<script>$('footer').css('background', 'black');</script>
</body>
…
…
<script>
var jQl = …
jQl.loadjQ('jquery.min.js');
$('footer').css('background', 'black');
</script>
</head>
…
jQl from Cerdic/jQl
One of the many reasons we like jsDelivr is because it provides a unique file combiner, which eradicates extraneous requests which, especially with smaller files, can add considerably latency (literally) to your page.
…
<script src="assets/js/rem.min.js"></script>
<script src="assets/js/prefixfree.min.js"></script>
<script src="assets/js/jquery.min.js"></script>
…
…
<script src="https://cdn.jsdelivr.net/combine/gh/jquery/jquery@3/dist/jquery.min.js,gh/chuckcarpenter/REM-unit-polyfill@1/js/rem.min.js,gh/LeaVerou/prefixfree@1/prefixfree.min.js"></script>
…
According to CDNperf, jsDelivr offers one of the lowest latencies of any CDN. Latency is the time a users computer takes to find a site, so a lower latency means starting to load sooner. Stay away from Yandex unless your sites users are local to it, and you should be fine.