between this
<script src="js/script.js"></script>
and that
<?php
echo '<script>';
include 'js/script.js';
echo '</script>';
?>
Which is better?
I'm actually wondering about things like HTTP Request and others stuffs...
(the same goes for CSS styles, should I put everything in the same file and send to the user, thus reducing the amount of requests, or should I properly separate just like everyone else do? thus increasing the number of requests)
There is something else that I should be concerned about?
Ok, it took me second to figure out what you were asking. In your first choice you are outputing a script tag that links to your javascript, in the second you using PHP to include your javascript inline.
Of the two choices, the first is by far the best. Assuming your page content is dynamic, due to browser caching, for every page a person downloads from you, the same javascript will be included everytime. If your javascript is 100kb in size, every page is now an extra 100kb. Over time this will add up for both your server and your clients.
Including your Javascript (and CSS) by linkages allows the browser to cache pages, and only fetch what is necessary. This will similarly reduce the number of requests as a browser will only fetch what is necessary, which in most cases is just the HTML page.
edit: What if the script is used on only one page?
Still include the Javascript by a link, rather than inline. If you page is 100% static, but has thats not one page but many. And each request will get a new output, with the same replicated Javascript. Even if your page is pure-static HTML, still include it by a link as you never know when you might want to reuse the Javascript (or CSS) code.
I would consider something like this
<script src="js/js.php"></script>
where js.php includes all the need js files I assume this will resolve the caching issue, plus you can make things dynamic by adding get values I guess.
btw I find it better to use the php open and close tags for html whenever possible
<script src="<?php echo $var ?>" ></script>
As I commented before, <script src="js/script.js"></script>.
This is in you <head> and it will be implemented before anything goes into you <body>
Since you are building your front end via JavaScript, php functionality will come after everything was built by JS.
Well according to me using the later approach is better , if you are designing a php page it is always better to write everything in php , whereas HTML side scripting is better done inside echo"" or print""; functions , you can read a lot about it in w3schools.com , hope my answer solved your problem.
Related
In HTML is there such a line of code that will do the same thing as PHP's require_once? I'm just curious because there are some lines of codes that I want to duplicate through multiples sheets without needing to require myself to type it each page.
I know I can do it via PHP, but I am looking for an HTML variant? Is there such a beast or am I barking up the wrong tree?
That depends on what you want to include. Including a PHP-File is not possible, if you want to include a CSS stylesheet, use:
<link rel="stylesheet" type="text/css" href="yourstylefile.css" />
and for a Javascript file
<script type="text/javascript" src="yourscriptfile.js"></script>
Of course you have to put that code between the header-tags.
No, there is no include mechanism in HTML. Unless you count SSI.
Edit: wait, "sheets"? You mean CSS?
Yeah, SSI is the closest you're going to get. However, there are many non-server-side ways to get around this. Several web development applications have html templating systems that replicate server-side includes on the development side. For example, dreamweaver allows you to insert repeatable regions into HTML templates. When you modify the "included" file, Dreamweaver will modify all HTML files that use that block. As this is not a true include, but rather an HTML-updating system, you do have to then re-upload these files if you use a remote server, but if you have to stick to plain HTML it can make projects much more manageable and is much better than using iframes.
Lastly, there is also the option of having Javascript build a repeating block of code. You can simply include a common javascript library on every page <script type="text/javascript" src="templater.js"></script> and have it build the element on the client's side (either with an innerHTML call or inserting elements into the DOM). This has the obvious downside that
It requires Javascript to work
It might mess with SEO
It may slow down page loads (from the client side anyhow)
Using a proper include in a server side language is of course the best approach, but in a pinch these are both potential alternatives.
Technically you can create an iframe on your page which will load and handle a separate page but it does not function like include or require once. And to this I know of no alternatives.
Simple and fast question:
I need the jquery library for a site, so I access it in my header.php file as such:
<head>
<!-- include jQuery library -->
<script type="text/javascript" src="../javascript/jquery.js"></script>
</head>
Now my question is should I also be putting some other php scripting in there to make sure it is only included when I need it for a given page? My gut tells me I am absolutely right to only load the jquery files when I need them, yet I swear I always see things like this loaded without thought to if they are actually needed for the given situation. So perhaps there is no harm in always having it there.
So should it be like this?? Pseudo code:
<head>
<?php
//set jquery variable to true or false in configure.php file based on situation
if($jquery){
//include the jquery script!!
}
else{
//jquery??? we don't need that here
}
?>
</head>
It's generally better to load only what you need for a page, but if you do include jQuery everywhere, make sure:
1) It's minified (to reduce overhead).
2) You serve from a CDN (e.g. Google's). The likelihood of the user having a cached version (and thus a faster page load) will be much higher. See:
http://encosia.com/3-reasons-why-you-should-let-google-host-jquery-for-you/
It's not that big a deal.
Keep in mind that (most) people's browsers will cache files, for at least a certain duration of time. If say your homepage doesn't require jQuery, but the about page does, people with slower internet connections will be suffering a longer page load duration on your about page.
Even so, you should absolutely try to use minified versions of jQuery to reduce the amount of data you have to serve, and your users have to download. Even better is to use a CDN like Google's, as they're optimised for distribution to users, and also because with it in use widely, people are more likely to have it already cached on their system. HTML5 Boilerplate has a nice way to include jQuery from the Google CDN, and use the copy on your server as a fallback:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.js"></script>
<script>window.jQuery || document.write('<script src="path/to/jquery-1.5.1.min.js">\x3C/script>')</script>
The issue of longer page loads can also be somewhat offset by having your jQuery include tag before the </body> tag, as scripts and stylesheets block page load until they're fully downloaded (for the majority of browsers). The only issue with doing that is that anything that depends on jQuery for site interaction of course won't respond immediately.
Given, if you absolutely want to conditionally include jQuery, that code snippet you provided should work fine.
Does going from
<script type="text/javascript" src="jquery.js"></script>
to
<script type="text/javascript">
<?php echo file_get_contents('jquery.js'); ?>
</script>
really speed things up?
I am thinking it does because php can fetch and embed a file's contents faster than the client's browser can make a full request for the file, because php isn't going over the network.
Is the main difference that the traditional method can be cached?
It may be faster on the first page load, but on every subsequent load it will be much slower. In the first example, the client browser would cache the result. In the second, it can not.
If you only ever serve one single website in your client's life, then yes, because you only have one HTTP request instead of two.
If you are going to serve multiple sites which all link to the same javascript source file, then you're duplicating all this redundant data and not giving the client a chance to cache the file.
You need to transfer the bytes to the browser in both cases. The only difference is that you save a HTTP request in the latter case.
Also make sure to escape the javascript with CDATA or using htmlspecialchars.
If you include your JS lib in your HTML page, it cannot be cached by the browser. It's generally a good idea to keep the JS separate from the normal HTML code because the browser can cache it and does not need to fetch it on subsequent requests.
So to make it short, it's an optimization that works only if the page is called once by the user and jquery is not used on other pages.
Alternatively, you may want to use the jquery from google apis - with the effect that they are often in the browser's cache anyway, so there is no need to transfer the lib at all.
It does so for that ONE PAGE.
All subsequent pages using the same library (jquery.js downloaded from the same URL) SUFFER, because if you include the reference to the external file yes, it has to be downloaded in an extra connection (which is relatively cheap with HTTP\1.1 and pipelining), BUT - provided your webserver serves it with useful headers (Expires:-header far in the future), the browser caches that download, while with the "optimization" it has to retrieve it with every single content-page.
Also see pages like this one:
http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
(the keyword here is "revving" in connection with those far-future expiration dates)
The first one is better since the browser can cache the script. With the second version it will have to re-download the script every time it loads the page even if the script didn't change.
The only time the second version is an improvement for scripts that cannot be cached by the browser.
It depends on how many files use the same file. However, in most situations this will be slower than your first piece of code, mostly because jquery.js can be cached.
Yes, that would initially be a performance optimization regarding the number of HTTP-requests being used to serve the page - your page will however become a bit bigger per pageload as the jquery.js will be cached in the browser after the first download.
It does if your page is static.
But if its not static your browser will download the page very time while jquery doesn't change but still included. if you use src="jquery.js" and the page changes, the browser will load jquery from cache and not download it again so using src="jquery.js" is actually faster.
Hey guys quick question, I am currently echoing a lot of javascript that is based conditionally on login status and other variables. I was wondering if it would be better to simply echo the script include like <script type="text/javascript" src="javascript/openlogin.js"></script> that has been run through a minifying program and been gzipped or to echo the full script in raw format. The latter suggestion is messier to me but it reduces http requests while the latter would probably be smaller but take more cpu? Just wondering what some other people think. Thanks in advance for any advice.
I would go the first option, even though its an extra request it means the html/php page will be smaller. Also, it is my understanding once the Javascript is cached it won't be requested again whereas the html/php page will be requested every time.
Depending on your javascript functionality you could also add the async="true" to the script include to ensure the page is downloaded first then the javascript.
Include it externally (your first option). Then when you're doing javascript maintenance, you're not doing it inside PHP as well.
Including the raw text is preferred if you do not expect the page loads per user to go much beyond 1. If you expect your users to request your page multiple times, then the external, cacheable include is the right option. This is usually the case.
Echo the script include so that the javascript in in an external file and then the browser's cache can do it's job.
i have divided various components of the page in different php file. In the navigation php file i have the objects i want to use in the javascript.
where should i put the javascript <script ...> so that it loads fine? right now i am putting it in a completely seperate file header.php? but i dont think the javascript is picking objects from nav.php
i hope i am making sense ;)
The standard suggestion is that you should put all of your SCRIPT links prior to your closing BODY tag at the bottom of your document. This streamlines network connections:
http://developer.yahoo.com/performance/rules.html
It doesn't matter where in the PHP rendering process you put it, it only matters that when the output HTML and javascript are combined, the HTML elements exist before you try to access them in javascript.
It's for this reason that most javascript toolkits have a function for executing javascript once the page elements are loaded, such as jquery's document.ready function.
Generally the advice is to put the <script> at the bottom of your HTML page.
http://developer.yahoo.com/performance/rules.html
My understanding is that the best speed comes from putting the script at the end of the page?
http://developer.yahoo.com/performance/rules.html
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.
Noet that the performance benefit you gain from repositioning the tags (or using more esoteric methods for avoiding blocking) is very small compared to the benefit of getting them cached correctly at the browser.
C.