style.css vs style.php

I'm considering cutting down my bloated CSS code as much as possible by switching from style.css to style.php. In this case, I would use CSS variable.

Do you think is a good idea in term of performance (long term).

I mean give me a bit technical support theory if possible.

I'm on PHP 7.

Thanks,

 

Never mind,

base on my research browsers don't cache PHP script.

 

I was about to say, no clue where you got the idea that putting it into a PHP file would be faster, or better, or even something that should be done. That's as silly as using the STYLE tag or 90% or so of the cases where people use the STYLE attribute or set element.style values from their JS.

Though with cache-control you could force them to be cached, it's still a waste of processing time moving what should be a static unchanging file into an inherently dynamic format the server MUST spend more time processing by calling PHP.

Really if you've got "bloated CSS" it probably means faulty methodology, dumbass frameworks or preprocessor nonsense, pissing on caching and sizes by using 1970's style base64 to force a file into the markup or CSS, or equally broken HTML in need of fixing.

 

You are not going to find a faster way of doing CSS then just having the external file in the head of the page so the server sends it across. However if you need optimization that suggest that either you have many css files, or your CSS is bloated with a lot of stuff you don't need.

I go away from all that by going to a CSS database to separate pages from CSS rules. Every page has single CSS file with everything it needs to support both the content and the theme without carrying around junk it does not need. The CSS files are in the range of 10k to 20k. To re-theme all I have to do is use a maintenance job or an sql script to update the rule changes and then it takes less than 15 seconds to regenerate all the stylesheets.

For an existing site it is a bit of work to convert, but it follows my normal approach of doing the work up front to reduce maintenance time. for a new site it is easier than conventional methods and external stylesheets can be load to the db with simple scripting unless they are really malformed and screwed up.

 

Hi @COBOLdinosaur,

Thanks for the tip. This is the first time I've heard about it.
I'll take some times digging it in deep. Is that the one on your signature?

The web site I'm working on is an e-commerce selling used products ranging from shoes to a warship. You can imagine the mess.
It isn't mine and isn't built by me.

Though I mostly work on the real-time and the automated systems, I have to have the part of my work which involved with CSS and HTML.

I've been thinking of the most efficient way and don't mess with the work of the others, which are totally mess with thousands line of code. I don't even dare of looking at it.

 

Which is the OPPOSITE of efficiency to me since it means sending a unique css file with every page; if you have enough unique styles that it's providing a "benefit" there's likely something wrong with the site... Unless you have a unified sheet of all the like styles being sent too, you're missing the ability to pre-cache appearance of subpages... and if you're sending two files, that's an extra handshake so...

It's why I advocate a single monolithic stylesheet -- one file means one handshake, you've pre-cached the appearance of all your sub-pages (which also speeds rendering of subpages) and if your total CSS is big enough that once sent gzipped it makes ANY difference in loading time, there's something wrong with your site's CSS.

But again I SAY the largest the CSS for an entire site should ever reach is 48k; but that's me Mr. Scotting the number. 24-25k of CSS should gzip down to 5-6k. If one 5-6k transfer you ONLY NEED TO DO ONCE is an issue and you feel the need to break it into separate files... that's delusional.

That or listening to Google Pagespeed's bullshit advice since at this point they're just packing it full of shit to try and dupe people into spending for their idiotic "service" or into buying CDN space.

Well, that or your server isn't set to serve static files compressed, you're using presentational classes, pretty much ignoring semantic markup, using HTML 5's gibberish and pointlessly redundant ALLEGEDLY semantic "structural" tags, usign bold and lists to do headings + paragraph's or definition list's job, line breaks to do padding's job, and generally using sloppy coding practices.

... like your page about using "CSS Databases" -- I mean hell you've got charset after the title tag forcing a reparse, and 25k of HTML doing 20k or less' job. Much less the 11k of markup on a page I somewhat doubt should have more than 8k if you only have the style for one page; that isn't responsive, gracefully degrading, or any of those other things I'm always ranting and raving about -- of course that's before we talk the outdated crap no serious developer would waste time on like the 1990's style stat counter, "best used in ___ browser" asshattery, etc, etc...

 

Thanks @deathshadow, for additional info.

I have another question. I plan to revamp the web site on my signature as soon as I finished contracted tasks.

Do you think is it a good idea to have one stylesheet for the entire web site.

Currently I have two stylesheets, one for the welcome areas like when you visit facebook (including login, signup, TOS, blah blah blah) which has different layout than after you logged in, and the other, of course, for the logged in area.

Do you consider this as bloated to combine the two.

Thanks,

 

That's what I mean by a monolithic stylesheet. If you keep everything in a sensible order, use classes and ID's by meaning and not appearance, properly leverage existing tags (that cascading part of CSS) before diving for the classes and ID's, and have a proper semantic markup that lets you re-use the same styles across all your pages, it's just simpler/easier to have one file. One handshake per media target, one place to look to make corrections, one item for the server to deal with and compress, one file for the browser to cache.

... and the importance of pre-caching of sub-pages appearance ahead of time cannot be overstated, at least if you expect people to, oh, I dunno... visit more than one page of your site.

Every time you have a page load with another unique file, it's more work for the server, more work for the connection, more work for the renderer. It's why you'll hear me ALL THE TIME bitching about people having hundreds of K of CSS or Scripttardery in dozens of files. MOST people trying to defend against that focus on the file sizes, when really the file COUNT is the more important number.

Remember, REAL WORLD middle-of-the-road every file past the first eight on a website ASSUMING there's enough free connections at both ends (running a torrent in the background? Wifey watching Netflix? Yeah, forget it) is a 200ms -- that's a fifth of a second, REGARDLESS OF YOUR CONNECTION SPEED -- worst case scenario can be a full on second or more per file, INCLUDING the first eight. You might have seen me suggest testing how a site behaves at a crowded location with free Internet like a coffee shop -- that's why. Choked out connections with tons of users, aka a REAL WORLD scenario.

You also have to keep in mind regionalisms; some places have magical fantasy-land connection speeds and ping times, other places not so much; so that bloated train wreck sucking down two megabytes in 100 files may have a empty-cache first load of 5 seconds for the person sitting on top of the server in that fantasy-land, but could take over a minute and a half for someone just down the road.

One must also figure in that as connection speeds do get faster, handshake times do NOT, so sure, those sizes are less of a concern, but that time spent with the server AND the client having their thumbs up their backside waiting on handshaking could be better spent actually transferring data!

It's why I suggest practicing size targets -- where 72k in 3 files NOT counting content is an upper limit for a template's HTML+CSS+SCRIPTS. Laugh being MOST people blow past that limit before they've even written any code of their own thanks to the bloated, slow, idiotic, halfwit, mouth-breathing dumbass BULLSHIT known as "frameworks" -- none of which are worth a flying purple fish.

You combine it down, that's one file to compress on the server with gzip, one handshake to the client, and you're pre-caching sub-pages appearance. (another reason to get as much appearance out of the damned HTML as possible) -- in my mind that's the opposite of bloat even if some of the unique sub-styles go unused. That may sound odd -- sending more data even when unused is less bloat -- but in the overall scheme if people visit more than one page of your site, or if you are on choked out connections on the host OR at the client side, it pays far bigger dividends. Same goes for images re-used across pages, especially small ones like icons. The incorrectly named "CSS Sprites" exists for a reason after all -- the SAME reason I say use one stylesheet per media target!

Basically with websites more code is a bad thing, but more files is worse. A concept that seems lost on a few folks like the people behind things like CSSLint, YSlow and Google PageSpeed -- all of which started life as useful tools, but in recent years seem to have gone the route of bad advice designed to sell you something.

-- edit -- Oh, multiple files can get even worse depending on how many cookies you use! Every file request has headers and cookies are sent with EVERY header in both directions. Less files means less cookie overhead too -- but there are other techniques for eliminating such overhead as creating a subdomain for static files that don't use the cookies and using domain specific cookies. That way files sent from your subdomain don't have that overhead... though worrying about that comes down to just exactly how one is or is not using cookies. If you only have a few cookies the overhead of the separate domain in the markup or stylesheet can end up not worth the time and effort. You go "knee deep" into "cookies for everything", it's well worth the effort of setting up a separate domain for static files. More so if you leverage a lighter-weight http server for that domain like lightppd separate from the more complex one needed for CGI/SSI/SCV/whateverTheyreCallingItThisYear.

EITHER way, less files means less overhead. It's why less separate image files is good, it's why a monolithic stylesheet is good, it's why when possible as many scripts as you can should be combined into a single file for deployment...

It's also why for my own stuff I try not to ever have more than 16 separate files, not counting the social media stuff or things like disqus over which I have no control.... the only real exceptions to that being things like image galleries which obviously would have more files in the form of thumbnails.

 

The performance based on a lack of caching is a straw man argument. It starts based on the incorrect assumption that there is a one-on-one relationship between pages and stylesheets. It is possible that such granularity might exist on a very small site, but generally content shares most CSS in a given section, and on an ecommerce site with multiple prduct lines there might be 25 or 30 small stylesheets for several thousand pages. So the small additional penalty for not caching would happen only occasionally when a user move from one section to another.

The average increase in load time would not be high, and would be offset by the part of loading being ignore in the argument; processing unused rules. The CSS parser has to parse and serialize every declaration for every page load whether or not the file comes from cache or the server. It has to parse all the unused rules because at load time it has no way of knowing what will actually be used. The additional rules also add additional load on the rendering engine which has to attach computed values during both the layout and paint phase using the collection of rules that has been bloated with unused rules.

Changes in the computed values of properties mean the render object attached to each element must traverse a larger collection of property/value pairs in the render engine memory (Firefox hash table), stylesheet object (webkit and blink), or document object (some jquery crap). I am not sure about Trident but it looks like it is using an MS proprietary object. The time penalty on the rendering engine is not huge a 50 rule sheet compared to 150 rule sheet might result in the rendereing engine being able to execute one or two additional re-paint iterations per second depending on the speed of the cpu.

So is it more work? Converting an existing site is quite a bit of work. Doing a new site is less or equal work depending on where the initial styles come from. Consolidating a load of crap because a site uses a boatload of sheets from multiple plugins is much less work than trying to rationalize the sheets and eliminate duplication, conflict, unused rules, and restrictions. Also the entire job does not have to be done in a single pass. The DB only exists in dev so it has not direct impact on the performance of the production environment.

It does not make any difference to me if someone tries this approach or not. I use it because it reduces the work I have to do during maintenance; and it gives me maximum flexibility for the kind of experimentation I do. So if it gets ignored, implemented, modified to morph into a variation, or just serves as an idea/debate generator does not matter. I'm not selling anything, generating revenue from ads, or recruiting followers. I just show folks some of the things I have tried and give them enough code to get started if they are interested in exploring.