SitePoint Sponsor

User Tag List

Results 1 to 10 of 10
  1. #1
    SitePoint Zealot
    Join Date
    Sep 2005
    Location
    Perth, Australia
    Posts
    137
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    what is better markup?

    Have a couple of questions regarding my XHTML markup.

    For CSS is it better to use

    Code:
    <link rel="stylesheet" href="/css/mystyle.css">
    or

    Code:
    <link rel="stylesheet" href="http://www.mysite.com/css/mystyle.css">
    With Javascript the same question, is it better to use

    Code:
    <script src="/js/theme.js"></script>
    or

    Code:
    <script src="http://www.mysite.com/js/theme.js"></script>
    Finding some people are complaining my site loads slow and I have notice it on older versions of IE

  2. #2
    SitePoint Addict
    Join Date
    Sep 2005
    Posts
    267
    Mentioned
    3 Post(s)
    Tagged
    0 Thread(s)
    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.

  3. #3
    Community Advisor silver trophybronze trophy
    dresden_phoenix's Avatar
    Join Date
    Jun 2008
    Location
    Madison, WI
    Posts
    2,729
    Mentioned
    31 Post(s)
    Tagged
    0 Thread(s)
    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

  4. #4
    Programming Team silver trophybronze trophy
    Mittineague's Avatar
    Join Date
    Jul 2005
    Location
    West Springfield, Massachusetts
    Posts
    16,432
    Mentioned
    160 Post(s)
    Tagged
    1 Thread(s)
    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.

  5. #5
    SitePoint Evangelist silver trophybronze trophy
    Join Date
    Jul 2013
    Posts
    406
    Mentioned
    21 Post(s)
    Tagged
    0 Thread(s)
    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)?

  6. #6
    SitePoint Mentor bronze trophy
    John_Betong's Avatar
    Join Date
    Aug 2005
    Location
    City of Angels
    Posts
    1,578
    Mentioned
    62 Post(s)
    Tagged
    3 Thread(s)
    Hi motion2082,


    >>> Finding some people are complaining my site loads slow and I have notice it on older versions of IE

    Try this:
    PHP Code:

    <?php 
       
    # http://stackoverflow.com/questions/19374843/css-delivery-optimization-how-to-defer-css-loading

       
    $fCSS 'relative/path/to/styles-sheets.css';
    ?>

    <script type="text/javascript">
      var stylesheet = document.createElement('link');
      stylesheet.href = '<?=$fCSS;?>';
      stylesheet.rel = 'stylesheet';
      stylesheet.type = 'text/css';
      document.getElementsByTagName('head')[0].appendChild(stylesheet);
    </script>
    The script was discovered after following a Google Page Load Faster Recommendations:

    "http://developers.google.com/speed/pagespeed/insights/?url=www.johns-jokes.com"
    Last edited by John_Betong; Nov 14, 2013 at 22:54. Reason: spelling: not my fortay

  7. #7
    Programming Team silver trophybronze trophy
    Mittineague's Avatar
    Join Date
    Jul 2005
    Location
    West Springfield, Massachusetts
    Posts
    16,432
    Mentioned
    160 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Francky View Post
    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.

  8. #8
    SitePoint Evangelist silver trophybronze trophy
    Join Date
    Jul 2013
    Posts
    406
    Mentioned
    21 Post(s)
    Tagged
    0 Thread(s)
    @ 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).

    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).
    • See here the FOUC with your homepage, if the stylesheet is added afterwards by javascript!
    • 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:

    1. I go to developers.google.com/speed/pagespeed/insights/?url=www.johns-jokes.com.

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

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

    4. 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!
      • 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.

    5. 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!
    • In your case the (1 used) stylesheet vo13-scrn-nor.css is only ... 1,36 KB (1.393 bytes), downloaded in 0.008 seconds.
      Then you can safely waive the Google Suggestion: not much to win!

    =======
    @motion2082:
    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.

  9. #9
    SitePoint Mentor bronze trophy
    John_Betong's Avatar
    Join Date
    Aug 2005
    Location
    City of Angels
    Posts
    1,578
    Mentioned
    62 Post(s)
    Tagged
    3 Thread(s)
    Hi @Francky ;

    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:

    "http://stackoverflow.com/questions/19374843/css-delivery-optimization-how-to-defer-css-loading"

    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.

  10. #10
    SitePoint Evangelist silver trophybronze trophy
    Join Date
    Jul 2013
    Posts
    406
    Mentioned
    21 Post(s)
    Tagged
    0 Thread(s)
    @John_Betong
    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 this 2001 article (see also wikipedia).
    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.

    ========
    @motion2082
    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").


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •