Ability to specify CSS path

[digitalpoint]

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...

$config['cssUrl']  = 'http://c.dpstatic.com/css';

 

[Mike]

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.)

 

[digitalpoint]

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

	chdir('/home/sites/forums.digitalpoint.com/web');
	include_once('css.php');

 

[bambua]

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.

 

[digitalpoint]

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.

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.

 

[Mike Tougeron]

You can adjust this via code if you extend the Dependencies & Template classes.

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

$fc = new XenForo_FrontController(new IGNXFAddons_Dependencies_Public());

It still processes the css.php, it's just hosted on a different domain

 

[DBA]

You can adjust this via code if you extend the Dependencies & Template classes.
.....
It still processes the css.php, it's just hosted on a different domain

How would a less technical guy go about implementing this?

 

[Mike Tougeron]

How would a less technical guy go about implementing this?

There isn't a way.

 

[Ketola]

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.