I don't think the src attribute will slow down your website even with what path you choose. It might be that the actual script itself is the real issue. I always use the relative path for including source files into my project as if I move to a new domain or subdomain I can easily just upload it without having to make too many file changes.

The usual bottle necks are seldom related to issues you mentioned in your OP. Relative / Absolute links presents benefits or detrment only if you plan to migrate the site, change site structure or access content remotely.

It is possible if you depend on .js for layout or effects ( already a bad idea in itself) that it is teh EXECUTION of your script that slows down the site. For example lets say your theme script is attaching event listeners to EVERY single element ( why!?!?). Also AJAX dependent sites are going to take a big performance hit; think abaout it each AJAX call is like loading a new page into your current page.

Watch out for preloaders too.... having many large images on a slide show that preloads .. OMG!

I would also check the sizes of your BG and content images or the number of images ( even small ones) that you have. Again , each image is a http request and that cost time; one 150k image loads faster than 150 1k images. if your site has dozens of small images, consider using a sprite.

I think I saw mention years ago that browsers cached files with relative paths but not those with absolute paths.

I don't know if this was or is true (I've never looked for it in HTTP headers) but I imagine that even if true, it wouldn't make much difference unless the files were monster sized, and even then most likely only an insignificant amount compared to what has been previously mentioned.

Wasn't it so that an absolute path does ask a new DNS-lookup (search for the domain/server) before retrieving the file, where a relative path is already on the server, and can handle the file request faster (in both cases: cached or not)?

Wasn't it so that an absolute path does ask a new DNS-lookup (search for the domain/server) before retrieving the file, where a relative path is already on the server, and can handle the file request faster (in both cases: cached or not)?

Thanks, while reading your reply it looked so familiar I'm sure that's what it was.I doubt DNS lookups would slow things down a noticeable amount.

@ Mittineague:Indeed, this will not make such a big difference as the points dresden_phoenix mentioned above.

=======@John_Betong:This script is "postloading" the css-file, if placed in the end of the page code (just before the </body></html> tags).

If placed in the <head>, it's just the same as a normal stylesheet link, which blocks the rendering: no effect.

BTW, shouldn't it be: stylesheet.href = '<?php echo $fCSS; ?>'; instead of stylesheet.href = '<? =$fCSS; ?>'; ? Or is that the same in php?

Anyway, it could be done without php also: stylesheet.href = 'relative/path/to/styles.css';.

A <noscript> must be included: <noscript><link rel="stylesheet" href="styles.css"></noscript>.

But for IE 10 and before, document.createStyleSheet('styles.css'); should be used/added , and for IE11+ it has to be: document.createElement('style'); (see this MSDN-page).

See also [[U]Dynamically loading css stylesheet doesn't work on IE[/U] and the update in this page: [URL="http://www.vidalquevedo.com/how-to-load-css-stylesheets-dynamically-with-jquery"][U]How to load CSS stylesheets dynamically with jQuery[/U]](http://stackoverflow.com/questions/1184950/dynamically-loading-css-stylesheet-doesnt-work-on-ie).

Then another point.The script is postloading the whole stylesheet after loading the content. That is giving an awful FOUC (Flash Of Unstyled Content): first the text of the content will be rendered, than a waiting time for the download of the stylesheet, and afterwards the styles will be added (not simultaneously).

I see in the Overview of Suggestions: "Your page has 1 blocking CSS source. This causes a delay in displaying your page".

I click the "More" button ►, and there can be read:

I click the "Optimize the CSS display" link, and arrive at the page Optimize CSS Delivery. If I compare what is said in the Example and under Recommendations, my conclusion is:

A <style> block in the head is inefficient if it is not very small. Other drawbacks: it should be inserted in the HTML (!) of all pages of the site (enlarging the loading time of all next pages: there is no cached stylesheet!), and a change of these styles cannot be done for all pages at once, but has to be changed in all pages apart...

Note: in the Example the small.css for the javascript postloading styles should be named big.css! :eek:

If the stylesheet is large (otherwise no significant effect), it should be split into a part "Above the Fold" and a part "Under the Fold".

The "Above the Fold" part *) can be loaded in a normal aboveTheFold.css in the <head>.

The "Under the Fold" part underTheFold.css can be postloaded with the javascript in the end.

Many thanks for the detailed reply and especially for taking the time to create the FOUC demonstration page. (I have noticed this before and never knew it had an acronym). Your demo certainly highlighted the disadvantage of stylesheet delayed loading.

I did try and implement Google's recommendations but unfortunately the Google search revealed an example of the script but did not specify that the script had to be loaded just before </body></html>. The results were worse so I abandoned the idea. Details here:

I checked your site using Pingdom and was amazed at just how fast your Server loads the header. It was more than ten times faster than the Server I use and I thought mine was fast

Further testing using "GWT->Crawl->Fetch as Google" revealed that loading an HTML page instead of the PHP dynamic cached page took 46ms instead of 125ms so I amended the following lines to the .htaccess file and now have a SplashPage, which now wants automating

Apache looks first for "index.html" before looking for "index.php"

DirectoryIndex index.html index.php

Fortunately this does not affect any of the other dynamic pages.

The code you mentioned '<?php echo $fCSS;?>' instead of stylesheet.href = '<?=$fCSS;?>' is a shorthand form which saves typing eight characters and is also far more readable. The main reason the script uses a PHP variable instead of being hardcoded is to have a single page script for both Localhost and Online pages to cater for the different paths to the identical stylesheet.

I am pleased you highlighted the fact that because of the small stylesheet the Google's recommendations were best ignored.

@John_BetongThanks for the php shorthand explanation; I'm just a noob in php.

About FOUC and FONCThe name "FOUC" (Flash of Unstyled Content) was given by bluerobot in [[U]this 2001 article[/U] (see also [URL="http://en.wikipedia.org/wiki/Flash_of_unstyled_content"][U]wikipedia[/U]](http://www.bluerobot.com/web/css/fouc.asp/)).Mostly a FOUC has a firm relation with Internet Explorer.

In addition to the bluerobot article: there was/is a difference in the way IE and other browsers render a page.

Other browsers let the existing page be on screen, and overwrite the page when all stuff for the new page is downloaded.

Internet Explorer (anyway the old versions) is first erasing the page (> default white background), and then starts building the new page. With complex page + a slow connection and/or slow machine that's giving a delay with a blanc page. If you are going to a new website, it is not striking; but if you stay on a site and go to another page it can be annoying: a flash of the same header image is rather unwelcome.

In fact this is not really a FOUC (when content is presented, but without styles/design), but more what I call a "FONC": a "Flash Of No Content". *)

If I encountered a FOUC or FOUC/FONC, I added for IE an IE-only <meta> with a fading page-transition:

<meta http-equiv="Page-Enter" content="blendTrans(Duration=.35)">

Then the deleting of the old page is prohibited while IE is building the new one.