1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Ability to specify CSS path

Discussion in 'XenForo Suggestions' started by digitalpoint, Oct 16, 2011.

  1. digitalpoint

    digitalpoint Well-Known Member

    Similar to how you can specify JS and data URLs in the config, it would be nice to be able to do the same for CSS so you can route them through a CDN/cookieless domain like so...

    Code:
    $config['cssUrl']  = 'http://c.dpstatic.com/css';
     
    Amin Sabet, ses, mjda and 6 others like this.
  2. Mike

    Mike XenForo Developer Staff Member

    The CSS is all created dynamically though, based on the CSS templates. (And it is both cached on the server side, if you have that setup, and the client side.)
     
  3. digitalpoint

    digitalpoint Well-Known Member

    Yep... you could say the same about JavaScript though as well (as far as it being cached). Plus while the CSS is generated from a PHP script, it's not truly dynamic... at least I don't think so. Does the CSS ever change without it's URL changing? I assume the only thing that is going to change it are things that change the actual URL (variables like style, d, dir, css, etc.).

    It's something we have done on digitalpoint.com and it actually cuts down on server bandwidth quite a bit simply being able to route CSS requests through a cookieless domain. For example, this is our main stylesheet for digitalpoint.com: http://c.dpstatic.com/css.php?style...css,vbulletin-formcontrols.css,dpg.css,dp.css

    Ultimately c.dpstatic.com is on the same physical server as forums.digitalpoint.com, but it eliminates the payload of about 1.5k worth of cookies for each request (mostly related to Google Analytics). HTTP headers can't be compressed via gzip either, so that 1.5k worth of cookies becomes the equivalent of a 7-8k webpage that could be compressed. Compound that with the fact that this page I'm on now (for example) uses two different stylesheets. So if this was my initial page view, we more or less added the equivalent network traffic of a compressed 15k webpage just because we are transmitting all the cookies used for this domain.

    Multiply that out for a site getting let's say a million unique visitors per day (let's say each gets 3 different CSS files on average browsing around the site... some more, more less obviously)... That's 4.5k in actual network traffic we eliminate per user. We just saved 4.3GB of unnecessary network traffic in a single day by eliminating the unnecessary cookies from the CSS requests.

    Our implementation being on the same physical server as the main domain is really just about getting the cookies out of the HTTP request. The c.dpstatic.com/css.php is nothing more than this...

    PHP:
    <?php

        chdir
    ('/home/sites/forums.digitalpoint.com/web');
        include_once(
    'css.php');
     
    HWS, yavuz, Andy.N and 1 other person like this.
  4. bambua

    bambua Well-Known Member

    Actually the css file changes based on the page you load, it only actually loads the css that's needed for that page, that's why you see all the switches on the css lines if you view source on a page. It bases what it loads based on what the templates require. The timestamp on the css file call is only there to make sure it doesn't get cached when the software doesn't want it to be.
     
  5. digitalpoint

    digitalpoint Well-Known Member

    Right... that was exactly my point. The CSS file changes based on the URL, but if you use the identical URL the CSS file will not change. I wasn't proposing just using css.php with no parameters. I still would have it take (and use) all the normal parameters... just serving it from a cookieless domain is all really.
     
    Deebs likes this.
  6. Mike Tougeron

    Mike Tougeron Well-Known Member

    You can adjust this via code if you extend the Dependencies & Template classes.
    PHP:
    class IGNXFAddons_Dependencies_Public extends XenForo_Dependencies_Public
    {
        public function 
    createTemplateObject($templateName, array $params = array())
        {
            
    /*
             * @TODO: UPGRADE-CHECK: Make sure we run the same code as the parent class does.
             */
            
    if ($params)
            {
                
    $params XenForo_Application::mapMerge($this->_defaultTemplateParams$params);
            }
            else
            {
                
    $params $this->_defaultTemplateParams;
            }

            return new 
    IGNXFAddons_Template_Public($templateName$params);
        }
    }

    class 
    IGNXFAddons_Template_Public extends XenForo_Template_Public
    {
        public function 
    getRequiredCssUrl(array $requirements)
        {
            
    $url parent::getRequiredCssUrl($requirements);
            
    $url 'http://myotherdomain.com/path/to/xenforo/' $url;
            return 
    $url;
        }
    }
    and then in your index.php file
    PHP:
    $fc = new XenForo_FrontController(new IGNXFAddons_Dependencies_Public());
    It still processes the css.php, it's just hosted on a different domain
     
    HWS, DBA, Jay and 1 other person like this.
  7. DBA

    DBA Well-Known Member

    How would a less technical guy go about implementing this?
     
  8. Mike Tougeron

    Mike Tougeron Well-Known Member

    There isn't a way.
     
  9. Ketola

    Ketola Member

    Sorry for posting to an old thread, but I would like to second the request with more arguments for having CSS served from a separate URL.

    We want to serve all static content from CDN. Even though CSS is "generated dynamically", it's still static. It very rarely changes.

    Our CDN fetches content from our servers using origin pull, and would hence be able to cache the css.php without a problem.

    There are two key arguments for serving from a separate CDN domain:
    1. serving from a CDN moves the content closer to the client - this can have a huge impact for some users
    2. using a cookieless domain makes the request header smaller and hence the request faster
    Even though the content is cached on both the server side and client side (Expires: Wed, 01 Jan 2020 00:00:00 GMT), the "empty cache" experience for a first time visitor is presumably faster if majority of the content (i.e. CSS, JS and images) are served from a quick server close to the client.
     
    C3JCVSG and akia like this.

Share This Page