[Suggestion] Even lesser HTTP request by adding a "proxy" script

[Andy Huang]

Currently, we have really neat CSS handling mechanism (css.php) which allow us to select multiple CSS files that we need to one single call. However, specific pages may require additional css or javascript, which goes beyond the initially defined package, and additional calls are added.

Suggestion: Introduce proxy.php and some basic javascript.

Each time a CSS is needed, template designer or addon developer "registers" a CSS link or JavaScript link with the system. Then, template system can grab all those and combine them into one single request, IE:

<link rel="stylesheet" type="text/css" href="proxy.php?css[]=css.php&amp;#63;css=xenforo,form,public&amp;amp;style=1&amp;amp;d=1286902466&amp;css[]=css.php&amp;#63;css=attachment_editor,editor_ui&amp;amp;style=1&amp;amp;d=1286902466" />

proxy.php looks at the css array, curl/or local lookup the files it doesn't know, combine the files in the order requested, gzip the package, store as a cache, and output the file. So long as the request string are the same (IE: version not changed), it just fetches from the cache.

Same thing can be done for javascripts.

This will reduce the HTTP request for main page by 3 (3 js requests vs 1 js request and 2 css requests vs 1 css request), and other subsequent pages by a various amount.

 

[random]

I don't have any idea of what Andy is talking about but I support his suggestion!

 

[Mike]

For reference, the 2 CSS requests are by design. The first one loads all global CSS. The second one will load all page-specific CSS. We leverage very aggressive caching here, so this ensures that on the second page view, much less CSS is downloaded.

If we did it in one request, many pages would be redownloading all that global CSS.

We have thought about it for JS files, though it's trickier (and whether serving JS via PHP would be better for the server, I'm not sure).

 

[Andy Huang]

For reference, the 2 CSS requests are by design. The first one loads all global CSS. The second one will load all page-specific CSS. We leverage very aggressive caching here, so this ensures that on the second page view, much less CSS is downloaded.

If we did it in one request, many pages would be redownloading all that global CSS.

We have thought about it for JS files, though it's trickier (and whether serving JS via PHP would be better for the server, I'm not sure).

Ah, okay; 2 CSS design makes sense then.
Serving JS via PHP in the above described method will most likely not add loads; the reason for that is because we'd be caching the (gzipped too) and stream_copy_to_stream the output, which takes virtually no resources (especially in comparison to fopen and fread).

 

[Erik]

I'm pretty sure WordPress uses a similar "registering" system to ensure that any given CSS or JavaScript file is not included in the page more than once (it also handles dependencies).