motion2082 — 2013-10-15T04:28:57-04:00 — #1
Have a couple of questions regarding my XHTML markup.
For CSS is it better to use
<link rel="stylesheet" href="/css/mystyle.css">
<link rel="stylesheet" href="http://www.mysite.com/css/mystyle.css">
Finding some people are complaining my site loads slow and I have notice it on older versions of IE
patche — 2013-10-15T07:08:30-04:00 — #2
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.
dresden_phoenix — 2013-10-15T14:53:26-04:00 — #3
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.
These are but general concepts, but I hope they help
mittineague — 2013-11-14T19:55:48-05:00 — #4
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.
francky — 2013-11-14T22:35:18-05:00 — #5
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)?
john_betong — 2013-11-14T23:40:43-05:00 — #6
>>> Finding some people are complaining my site loads slow and I have notice it on older versions of IE
$fCSS = 'relative/path/to/styles-sheets.css';
var stylesheet = document.createElement('link');
stylesheet.href = '<?=$fCSS;?>';
stylesheet.rel = 'stylesheet';
stylesheet.type = 'text/css';
The script was discovered after following a Google Page Load Faster Recommendations:
mittineague — 2013-11-15T00:31:13-05:00 — #7
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.
francky — 2013-11-15T19:33:52-05:00 — #8
Indeed, this will not make such a big difference as the points dresden_phoenix mentioned above.
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).
- If the page was opened in a not focused other Tab in your browser, you can give a page refresh/reload over there to see what is happening.
- (testpage not IE optimized; look please in another browser)
As I understand the Google-recommendations properly, it reads as follows:
- I go to developers.google.com/speed/pagespeed/insights/?url=www.johns-jokes.com.
- 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...
- 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 "Prioritize Visible Content" link in the Recommendations is leading to the page Reduce the size of the above-the-fold content, which is giving more details.
But all this is in vain if the styles cannot be split, and if it's not a huge original stylesheet! :rolleyes:
- In your case the (1 used) stylesheet vo13-scrn-nor.css is only ... 1,36 KB (1.393 bytes), downloaded in 0.008 seconds.
That brings us back to dresden_phoenix's remarks about the usual bottle necks.
If you give us a link to the page/site, probably we can say more.
*) Note: this is the part of the page showed at first glance: 100% of the window height. So there has be payed attention to high resolutions: the Above part has to cover the largest window height.
john_betong — 2013-11-18T01:52:10-05:00 — #9
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.
Many thanks once again.
francky — 2013-11-18T18:10:57-05:00 — #10
Thanks for the php shorthand explanation; I'm just a noob in php.
About FOUC and FONC
The 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.
- A value between .2 and .5 (sec) did the trick.
- This is for IE8 and before; in IE9+ it doesn't work.
Last years I didn't see a lot of FOUC's/FONC's in my pages (viewed in IE7), so I don't use this <meta> anymore.
Back on topic, to get it above the snow: do you have a link to your slow page?
*) In css-tricks it's called a "Fajax" ("fake ajax").