| Re: including CSS & JS on only pages that need that CSS & JS [message #175598 is a reply to message #175597] |
Mon, 10 October 2011 21:36   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 10/10/2011 5:17 PM, Thomas 'PointedEars' Lahn wrote:
> Mr. B-o-B wrote:
>
>> On 10/9/2011 6:54 PM, Jerry Stuckle cried from the depths of the abyss:
>>> And files should be included using link tags, not directly included in
>>> the source file directly (unless they are specific to this page - in
>>> which case there is no need for conditional includes). That way file can
>>> be cached by the browser and/or routers between the web server and the
>>> client, decreasing both network traffic and server load.
>>
>> Again, my original post fits these specs:
>>
>> if (@isset $jerrys_css) {
>> echo "<link rel=\"stylesheet\" type=\"text/css\" href=\"jerry_css.css\"
>> />";
>> }
>>
>> Then just set $jerry_css = 1 when needed. Imagine that. You are not
>> decreasing network traffic, not increasing server load, cache is
>> irrelevant as it's only cached in the pages that need it, you are using
>> .js/.css via link tags.
>
> This looks increasingly like blind teaching the blind. As the subject is in
> fact partially on-topic here, since PHP can be used server-side:
>
Of course PHP can be used server side. But that's not the point.
Unfortunately, you are unable to understand some very simple concepts.
Let me try to educate you (although I already know that's about as
possible as teaching a pig to sing):
> 0. Routers do not cache HTTP requests. They usually work on lower levels
> of the TCP/IP stack, the Transport (TCP) and Internet Layer (IP), and
> usually see only TCP and IP packets. Not only is a HTTP message usually
> split into several IP packets, but also is the payload transported by
> such a packet reduced so that the packet size does not exceed the MTU of
> the link, considering the header information of the packet as well.
>
> So we can safely dismiss the suggestion that the composition of Web
> resources could affect packet caching, if that even happens (routers
> usually cache *routing information*), as completely b…ogus.
>
Intelligent routers/proxies can.
> 1. You cannot "use .js via link tags". Client-side scripts have to be
> included using `script' elements.
>
> It is the best current practice that all client-side scripts required
> for a document be included with one request, unless it is feasible and
> more efficient to load some of them dynamically when needed. Which
> usually means that the request triggers a server-side script that
> composes the response for that one script.
>
Not via a link tag. But it can be loaded externally, i.e.
<script src="myjs.js">
> 2. It makes no difference to the number of requests whether you include
> other stylesheets with the CSS @import rule or the (X)HTML `link'
> element. Cacheability is equal, too, as with the CSS directive the
> source code does not change as well. [The same applies for scripts
> being loaded dynamically.]
>
Incorrect. A CSS file that is linked from several different pages can
be cached by the client. Including the css in every page means it will
NOT be cached (unless that page is cached).
> The main difference is in compatibility. Rather ancient user agents
> would not support the `@import' rule but would support the `link'
> element:
>
> <http://w3development.de/css/hide_css_from_browsers/import/>
>
> [Much the same applies for dynamic script loading. It usually requires
> XHR support or sufficient DOM support, while the plain `script' element
> is more compatible and reliable.]
>
Again, incorrect. XHR and DOM support are not required; they have been
part of the HTML spec for years.
> 3. It does make a difference to the loading speed of a Web site and the
> network traffic caused by it if you create one response from content of
> several CSS resources, as that is only one request. Doing so is the best
> current practice. As for caching, it rarely makes sense to exclude CSS
> rules from the generated response even if they are not used.
> It really is a matter of loading speed/traffic vs. cacheability; usually,
> loading speed is considered to be more important, as local caches are
> usually large enough to handle the differences and visitors do not like
> to wait.
>
Yes and no. A blanket statement like this is dangerous. The first time
a large CSS file is requested it can be cached. But if it is a large
file, it may take a lot of time to load that first time - and normally
the first page is the most critical (people won't wait long for a site
if it starts out slow).
However, most CSS files are not that big to cause a problem, so in
general it can be a good idea.
> 4. Requests for client-side scripts should be caused last, at least after
> the requests for stylesheets:
>
> <http://code.google.com/speed/page-
> speed/docs/rtt.html#PutStylesBeforeScripts>
>
>
That's one opinion - but it is not necessarily true for all browsers.
Some will not display anything until the entire page is loaded; others
will display during the load phase.
It also depends on whether you have any client side scripting code which
runs on page load; if so, then those scripts should be loaded first.
> Bottom line: Fewer requests and smaller responses are better.
>
In general, yes, but again, not always.
> I have started writing a general resource builder in PHP to do that. So far
> it works without problems for client-side scripts even in a production
> environment:
>
> < http://PointedEars.de/websvn/filedetails.php?repname=JSX&path=%2Ftrunk% 2Fbuilder.php>
>
> (The ultimate goal is that it resolves dependencies of resources
> automatically.)
>
> Constructive comments are welcome.
>
>
> PointedEars
But none of any of this has anything to do with PHP. If you claim that
is so, please show me where any of this can be found in the PHP manual.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]