Is there any good reason why CSS and Javascript should not be sent inline? At the moment I am using external files for my CSS and JS but I am thinking of embedding everything in the html pages.
By the way my present output is GZIPed.You shouldn't put JS and CSS inline unless you are only using them on one page. If you have a big site with a bunch, or even just a few, pages that use the same CSS and/or JS, it's much easier to just edit the CSS or JS files instead of having them inline, because then you have to go through every page, which takes a lot longer than an external file.You shouldn't put JS and CSS inline unless you are only using them on one page. If you have a big site with a bunch, or even just a few, pages that use the same CSS and/or JS, it's much easier to just edit the CSS or JS files instead of having them inline, because then you have to go through every page, which takes a lot longer than an external file.
That's a red herring! The CSS can still be stored in one file and PHP can insert it into the HTML pages. So, is there really a good reason?By inline you seem to actually mean not-external whereas Sanim was comparing external files with using the style attribute for individual elements.
Once your visitors Download an external CSS file it can be cached so that they don't need to Download anymore CSS and can just Download HTML, but if you put the CSS into your HTML document then they'll be Download ing the same stuff again unnesserarly.I am talking about CSS in the html document between the <head><style>...</style></head>tags, so sorry if there is any confusion.
The tree talks about caching but this is also misleading.
First, the browser must be set to cache data and many are not, so they will just request the files again.
Second, even if data has been cached the browser still requests the file to see if it has been updated (200) or not (304). This request alone is some 800 bytes which equates to nearly 2k of data if it had been sent inside the GZIPed html file.
Third, all the data arrives in one instant if it is in one file, whereas if it is sent in separate files the client must read the first file before making subsequent requests for the CSS file. Since nothing can be displayed without the CSS this slows down display of any data already Download ed.
By the way, if you are going to do the test above make sure your browser is set up to cache.
So to sum up, 1) no more data is sent on the wire as the header check offsets any data included in the html file and 2) there is a significant improvement in display time when sending CSS in the html file.
If you don't believe me about the speed improvement try a test. I have set up a page. You can view it here. (<!-- m --><a class="postlink" href="http://hazelcreed.dyndns.org">http://hazelcreed.dyndns.org</a><!-- m -->) The English version includes the CSS and Javascript in the html page and the Spanish version sends them externally. Note the massive speed improvement sending them as one.
So, noting the above, is there any good reason to send the CSS or Javascript externally? Also reload it a couple of times so all the images are cached.First, the browser must be set to cache data and many are not, so they will just request the files again.The majority of browsers have caches.Second, even if data has been cached the browser still requests the file to see if it has been updated (200) or not (304). This request alone is some 800 bytes which equates to nearly 2k of data if it had been sent inside the GZIPed html file.A 200 and a file still takes more than a 304.A 200 and a file still takes more than a 304. That's not true! My CSS GZIPed is 1377 bytes and my JS GZIPed is 244 bytes, total 1621 bytes. The headers are uncompressed and add up to 1670 bytes. Also the first page has to load before these requests are sent, so, the whole process is slower. I would say in the case of my test it adds 3 seconds to the time it takes to display the page.
Also if you do the test using the ip (81.132.125.214 (<!-- m --><a class="postlink" href="http://81.132.125.214/">http://81.132.125.214/</a><!-- m -->) ) there is no DNS look up involved so the speed advantage is even more noticeable.That's a red herring! The CSS can still be stored in one file and PHP can insert it into the HTML pages. So, is there really a good reason?
It isn't a red herring because you didn't indicate at first that you were doing the includes from the server side. In general your theory is correct, though, that adding external references will slow overall page rendering at the browser, especially if the objects referenced are small. External css references will also be the root cause of "jumpy" page rendering.Ok Ray. So at what point does it become advantageous to start sendind external files. What sort of size.
Also that jumpy effect only happens with non-compressed HTML/CSS as the browser starts to display it before Download is complete but with GZIPed output it isn't displayed until it is all decompressed. This causes a delay before any content is displayed and then it suddenly jumps onto the screen.External files will become advantageous when you do not wish for your html pages to consist of bulk (or at least, partly). This 'bulk' would disallow search engines for better indexing of your pages, since these would have to 'read' through the CSS / JS lines first. Some search engines will only read X number of bytes of your pages before your pages stop and so they would index whatever a specific page got up to that point.
If you do not care about all of that, I see no reason of why not to use PHP in order to include the CSS / JS you would need in the html pages.Ok Ray. So at what point does it become advantageous to start sendind external files. What sort of size. I have no idea but it would have to do with the size of the external file versus the request overhead, including networking latencies.
Also that jumpy effect only happens with non-compressed HTML/CSS as the browser starts to display it before Download is complete but with GZIPed output it isn't displayed until it is all decompressed. This causes a delay before any content is displayed and then it suddenly jumps onto the screen.I'm not sure that's what I was talking about. Even when files are compress the browser will have an uncompressed page before it starts requesting the external components. It can easily render the page and then see font changes, margin/padding changes, etc. that would cause rerendering of some or all of the page. That's what I'm refering to.External files will become advantageous when you do not wish for your html pages to consist of bulk (or at least, partly). This 'bulk' would disallow search engines for better indexing of your pages...You make a good point. Search robots probably don't index external CSS and Javascript.
By the way my present output is GZIPed.You shouldn't put JS and CSS inline unless you are only using them on one page. If you have a big site with a bunch, or even just a few, pages that use the same CSS and/or JS, it's much easier to just edit the CSS or JS files instead of having them inline, because then you have to go through every page, which takes a lot longer than an external file.You shouldn't put JS and CSS inline unless you are only using them on one page. If you have a big site with a bunch, or even just a few, pages that use the same CSS and/or JS, it's much easier to just edit the CSS or JS files instead of having them inline, because then you have to go through every page, which takes a lot longer than an external file.
That's a red herring! The CSS can still be stored in one file and PHP can insert it into the HTML pages. So, is there really a good reason?By inline you seem to actually mean not-external whereas Sanim was comparing external files with using the style attribute for individual elements.
Once your visitors Download an external CSS file it can be cached so that they don't need to Download anymore CSS and can just Download HTML, but if you put the CSS into your HTML document then they'll be Download ing the same stuff again unnesserarly.I am talking about CSS in the html document between the <head><style>...</style></head>tags, so sorry if there is any confusion.
The tree talks about caching but this is also misleading.
First, the browser must be set to cache data and many are not, so they will just request the files again.
Second, even if data has been cached the browser still requests the file to see if it has been updated (200) or not (304). This request alone is some 800 bytes which equates to nearly 2k of data if it had been sent inside the GZIPed html file.
Third, all the data arrives in one instant if it is in one file, whereas if it is sent in separate files the client must read the first file before making subsequent requests for the CSS file. Since nothing can be displayed without the CSS this slows down display of any data already Download ed.
By the way, if you are going to do the test above make sure your browser is set up to cache.
So to sum up, 1) no more data is sent on the wire as the header check offsets any data included in the html file and 2) there is a significant improvement in display time when sending CSS in the html file.
If you don't believe me about the speed improvement try a test. I have set up a page. You can view it here. (<!-- m --><a class="postlink" href="http://hazelcreed.dyndns.org">http://hazelcreed.dyndns.org</a><!-- m -->) The English version includes the CSS and Javascript in the html page and the Spanish version sends them externally. Note the massive speed improvement sending them as one.
So, noting the above, is there any good reason to send the CSS or Javascript externally? Also reload it a couple of times so all the images are cached.First, the browser must be set to cache data and many are not, so they will just request the files again.The majority of browsers have caches.Second, even if data has been cached the browser still requests the file to see if it has been updated (200) or not (304). This request alone is some 800 bytes which equates to nearly 2k of data if it had been sent inside the GZIPed html file.A 200 and a file still takes more than a 304.A 200 and a file still takes more than a 304. That's not true! My CSS GZIPed is 1377 bytes and my JS GZIPed is 244 bytes, total 1621 bytes. The headers are uncompressed and add up to 1670 bytes. Also the first page has to load before these requests are sent, so, the whole process is slower. I would say in the case of my test it adds 3 seconds to the time it takes to display the page.
Also if you do the test using the ip (81.132.125.214 (<!-- m --><a class="postlink" href="http://81.132.125.214/">http://81.132.125.214/</a><!-- m -->) ) there is no DNS look up involved so the speed advantage is even more noticeable.That's a red herring! The CSS can still be stored in one file and PHP can insert it into the HTML pages. So, is there really a good reason?
It isn't a red herring because you didn't indicate at first that you were doing the includes from the server side. In general your theory is correct, though, that adding external references will slow overall page rendering at the browser, especially if the objects referenced are small. External css references will also be the root cause of "jumpy" page rendering.Ok Ray. So at what point does it become advantageous to start sendind external files. What sort of size.
Also that jumpy effect only happens with non-compressed HTML/CSS as the browser starts to display it before Download is complete but with GZIPed output it isn't displayed until it is all decompressed. This causes a delay before any content is displayed and then it suddenly jumps onto the screen.External files will become advantageous when you do not wish for your html pages to consist of bulk (or at least, partly). This 'bulk' would disallow search engines for better indexing of your pages, since these would have to 'read' through the CSS / JS lines first. Some search engines will only read X number of bytes of your pages before your pages stop and so they would index whatever a specific page got up to that point.
If you do not care about all of that, I see no reason of why not to use PHP in order to include the CSS / JS you would need in the html pages.Ok Ray. So at what point does it become advantageous to start sendind external files. What sort of size. I have no idea but it would have to do with the size of the external file versus the request overhead, including networking latencies.
Also that jumpy effect only happens with non-compressed HTML/CSS as the browser starts to display it before Download is complete but with GZIPed output it isn't displayed until it is all decompressed. This causes a delay before any content is displayed and then it suddenly jumps onto the screen.I'm not sure that's what I was talking about. Even when files are compress the browser will have an uncompressed page before it starts requesting the external components. It can easily render the page and then see font changes, margin/padding changes, etc. that would cause rerendering of some or all of the page. That's what I'm refering to.External files will become advantageous when you do not wish for your html pages to consist of bulk (or at least, partly). This 'bulk' would disallow search engines for better indexing of your pages...You make a good point. Search robots probably don't index external CSS and Javascript.