Support forums : The Future

avoid css @import?

The future of this project but not in a "I want a pony" sort of way. This is all about everything meta about Quam Plures. The general direction, the support tools, stuff like that.

Moderator: Dracones

avoid css @import?

Postby EdB » Thu Jul 21, 2011 12:01 am

http://code.google.com/speed/page-speed ... dCssImport

googlelabs is going to die so I figured I'd use http://pagespeed.googlelabs.com on one of my installations. Seems one thing they pointed out is something we might want to do for ALL our templates. Ultimately we need to dig on all our css stuff and avoid duplications and stupid shit, but if we can move from @import to a link rel="stylesheet" in the header doc then everybody always wins.

Thoughts?
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: avoid css @import?

Postby Tblue » Thu Jul 21, 2011 12:51 pm

Another good thing to do would be to compress all stylesheets used on a page into one big file and send that to the browser. :)
Tblue
Dracone
 
Posts: 340
Joined: Sat Nov 21, 2009 1:35 pm
Location: Berlin, Germany

Re: avoid css @import?

Postby EdB » Thu Jul 21, 2011 6:37 pm

Tblue wrote:Another good thing to do would be to compress all stylesheets used on a page into one big file and send that to the browser. :)

I wonder if we can do that server-side? The thing I want to avoid is ugly-ass files that don't help people who want to edit them is where I'm at with that.

BTW there was a whole bunch of shit there we can do to optimize pagespeed. The biggest hitters on my QP-powered site I did the report on was something about putting "cache this shit for a long time" in the header. I'm about 99% convinced we can send a smarter header with our pages but I've no idea how to get that stuff done. I have the pagespeed add-on on my chrome browser, so I'll get a link to a page that explains what I'm trying to talk about eventually.

Anyway what I think of for now is pretty simple: First we pull all the styles for the navbar into it's own file and do a link rel stylesheet for it if the person is logged in. That file we can semi-optimize by getting rid of all "visually enhancing" white space because editing that one is highly unlikely for most installations. A super-advanced CSS person can, but they won't mind the optimization approach. Second, I want to look at all the damned @importing we do and see about getting rid of it. Even after I put the three we import into one file and did a head link for it I *still* had the same file getting imported by other files. Go figure... Third, wrap up the second item in another branch for doing a link rel in the head.

Seems like a good place to go eh? I've only a little complaint with package bloat (and adding quality comments is never bloat), but anything we can do to measurably improve performance of created pages is a win for QP.
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: avoid css @import?

Postby EdB » Thu Jul 21, 2011 9:05 pm

Here's us getting a whopping 44 out of 100: http://pagespeed.googlelabs.com/#url=ht ... bile=false

IMHO that provides an awesome list of things we need to do to make QP inherently better than any other CMS out there. A really big one that I have no idea how to do is "leverage browser caching" http://code.google.com/speed/page-speed ... serCaching
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: avoid css @import?

Postby EdB » Fri Jul 22, 2011 8:26 am

https://code.launchpad.net/~edb/quam-pl ... ort_public

I was going to stop at getting the navbar and debug css out of "always delivered" and into a file that requires being logged in, but went for getting all the public-side @import of css files removed. To do that I took one file that was @imported by 2 others and simply dropped the contents into the others. I then turned all 3 files that were @imported by all templates into link rel stylesheet in the html_header file.

Did a wee bit on the admin side but gave up because it is a beast all it's own, and did not touch the style sheets that come from plugins.

ALSO opted to do a fair bit of "minification" on the cross-template style sheets. I personally don't like how they look, but they get delivered to visitors so it makes more sense to minify them than to keep them easy to read. The byte reduction is pretty freakin awesome, and in theory page loading is much quicker.

Off topic There is a lot more to do with pagespeed optimization. Delivering a header with "expires" requires pretending the css is a php file OR having mod_expires on your server. We can only control one of those aspects, so there you go. We also need to make sure our css is in the head prior to any javascripts, and that will include style sheets from plugins. This last bit MIGHT require that we redo certain aspects of how we include stuff because if I remember correctly we have one generic "include this stuff" function or hook. IF that is the case then we seriously need to treat css and js differently so that they can be included in the most optimum order (css first).

Oh and our attached images don't include height and width attributes. Totally freaking amazing. The damned file NAMES are the width and height, but we're not smart enough to include the attributes in the img tag? sheesh.
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: avoid css @import?

Postby Kimberly » Fri Jul 22, 2011 4:36 pm

We talked about minifying the css some time back. Another area is minification we might want to look at is any js we use as well. A good selling point for a CMS/Blog Engine is speed. I have seen some proggies that are either on very overloaded servers, or they are just slow at creating the page.
Kimberly
Dracone
User avatar
 
Posts: 842
Joined: Mon Jul 19, 2010 4:44 pm

Re: avoid css @import?

Postby Kimberly » Fri Jul 22, 2011 4:38 pm

Do we need to check all the template CSS files?
Kimberly
Dracone
User avatar
 
Posts: 842
Joined: Mon Jul 19, 2010 4:44 pm

Re: avoid css @import?

Postby EdB » Fri Jul 22, 2011 5:10 pm

At some point I think we should address them, but for now that was where I personally didn't want to do the "minify" thing because we do expect people to edit them. True that we *can* edit the files after removing as much white space and comments as possible, but it makes it harder to follow along. So I figured a couple of things. First the branch already handled a bunch of files and reached a point that was actually further than I had originally expected doing. Second there might be a way we can "minify on the fly" which would leave them human friendly for editing but make them speed friendly for delivering to visitors. Third we'll also want to address the admin side because it makes sense to do it. Fourth I figured "stop here before you fuck it up" :)

Edit Plus when I think of templates I think of the 55 we have between core and the templates series attached to core. As it is, if this branch gets merged I have to duplicate all the changes to /qp_templates/a_template/style.css in that other series, so laziness rears it's head ;)
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Re: avoid css @import?

Postby Tblue » Sat Jul 23, 2011 5:19 pm

Combining and minfying/compressing the CSS on the server-side should be possible I guess, with no user interaction (results would be cached, of course).

So we would have normal CSS files that one can easily view and edit, but what gets sent to the client would be compressed. Maybe one could turn that off when in debug mode or something.
Tblue
Dracone
 
Posts: 340
Joined: Sat Nov 21, 2009 1:35 pm
Location: Berlin, Germany

Re: avoid css @import?

Postby EdB » Sat Jul 23, 2011 7:18 pm

I saw a bunch of results when googling that topic. Basically one must make the trade-off between server CPU power and visitor experience. The general consensus was that visitor experience wins, but there are other drawbacks. Versioning the file name for example so that the cache gets effectively ignored (style.2.css is in cache but the page now wants style.3.css for example).

Oh wait I didn't learn anything about minifying CSS/JS server-side. That was compression of files. Seems to be html, css, js are the big ones for compression, but I found that if I simply cache type=html/text then the index.php page doesn't refresh when a new item is added. So I cut that down to 10 seconds.

Oh snap! I will do another branch to address our sample.htaccess file. "If mod_whatever.c then do all the caching thing for time by file type" significantly helped my page's score.

I also used a free service for lossless image compression. pagespeed complained about it so I figured why not, and got a few points of page speed out of it. That seems another thing we might want to implement on our image attachment thing. I know we have a "quality" setting for the resized images, but we don't have optimization.

Off topic I will note in passing that you will get a different page speed score AND suggestions for improvement if you use pagespeed.googlelabs.com versus the addon for chrome versus the addon for firefox. Since googlelabs is going away and I don't have a fancy enough firefox on my desktop I've been using chrome to do these speed test things.


Off topic BUT I got very pissed at how intro-type posts are treated like red-headed step children in postland. I want an intro-main with a readmore in it, but I can't freakin have that. In fact, intro-foo posts can not have a permalink page. More elsewhere...
EdB
Dracone
User avatar
 
Posts: 2072
Joined: Sun Nov 22, 2009 7:20 am
Location: Maricopa Arizona

Next

Return to The Future

Who is online

Users browsing this forum: No registered users and 1 guest

cron