that suggestion has been around for a while
Google recommends inlining small CSS
41–50 of 143 posts
Re: Google recommends inlining small CSS
#42Over time I've developed some opinions not shared by most. I only use a framework when under extreme duress. I use static pages wherever possible. I measure payload size. I'm also beginning to re-think CSS. I love CSS, but just like with OO, I'm thinking it may tempt us to think of structural considerations when we may just be wasting our time. I think the next app I write, I'm going to evolve my CSS, starting with i…
> ...I'm going to evolve my CSS, starting with inline styling, moving out to an inline style node in HEAD, then dynamically loading it from JS as in the Google example, and then finally using a class/series of classes. I'm sure it will load spectacularly fast, but that sounds like a maintenance nightmare. I spent a lot of effort on my "brochure" sites making sure that non-JS users will have a good experience (that in…
Yes, that's the standard answer: good structure costs very little now but pays off greatly in maintenance and upkeep.
And I believe it -- up until a point. After that point, too much structure becomes its own kind of hindrance, where you're looking at a UI and wondering "What the hell cascades do I have going on here to make that two pixels too far to the right?" (Or something like that)
So I don't think we disagree. The only thing I'm adding is that to determine the right amount of structure, add it in only as needed. So I imagine by the time you got to a multi-page site you'd be using external stylesheets and common classes. You just wouldn't start there.
Sure do like me some Bootstrap, though. And a good reset sheet is a no-brainer. Need to think about this some more. I think the key question is: how much of this do you really need?
For instance, right now I'm writing a small personal app to take a movie script in native file format and display it as a web page. Where did I start? With the function to do the translation, of course. Now that it's working, I can always manually execute it if I need to. I may just stop here. I've done enough.
If I really, really want something I can upload scripts to online, I'll write a page. Or two. Then I'll throw my uploaded file at my pre-existing function, return the file name, and I'm done.
I may have spent 10 hours on this so far.
By contrast, the "old" way of doing it was to start with setting up a site using all sorts of frameworks. Maybe decide on a color scheme. On the back-end side, I'd be creating a class graph and working through my persistence strategy. Maybe I could use Mongo! Wouldn't Ruby be awesome?
I tend to easily get focused on tooling and technique instead of just doing the fucking work. (Apologies for the profanity, but this took me a long time to figure out). So I've discovered for my own work, I need to concentrate on making sure I grow only the needed complexity. Nothing more. Way too easy for me to screw up in this area.
In the case of my little app, sure, I could start adding frameworks. Or I could just emit some HTML. Who knows? Maybe plain HTML with a few classes and some style information in the HEAD might be fine. That's a win.
Re: Google recommends inlining small CSS
#43Interesting. The sample code includes this bit: var raf = requestAnimationFrame || mozRequestAnimationFrame || webkitRequestAnimationFrame || msRequestAnimationFrame; if (raf) raf(cb); else window.addEventListener('load', cb); I've never thought to use requestAnimationFrame like that. When exactly does it fire? Is that the preferred callback these days for loading code after the page is "done" in some fashion? I've g…
I expect this to be on / before the first draw event, whereas the 'load' event takes place later (I presume)
Re: Google recommends inlining small CSS
#44The problem i've always had with this, and the "above the fold" rule as it appears in the pagespeed insights tool, is the definition of "fold" varies wildly. So I see CSS optimisation as a multi-step process. * Switch to a component-based rendering architecture (I favour React) * Map CSS rules directly to components (I use CSS Modules) * Have a JavaScript entry-point per route. The entry-point should only contain wha…
Does this have any negative effects on browser caching?
Re: Google recommends inlining small CSS
#45that suggestion has been around for a while
yeah this is not new was a recommendation from https://developers.google.com/speed/pagespeed/insights/ which I thought was now depracated, so must have been around for a while. I think it's a recommendation of http://yellowlab.tools/ too which is great.
Re: Google recommends inlining small CSS
#46I remember a CSS class in some enterprise software I was working on several years ago: /* bold */ .bold { font-weight: bold !important; } It has became my favourite real-world example of CSS misusage :)
One can argue if it’s a misuse or not. It’s quite handy to have such utility classes that rely on !important and can be used in markup directly. I have plenty of those in my stylesheets.
Re: Google recommends inlining small CSS
#47I love how they, in that example, use JS to load the rest of the CSS. Seriously?
Seriously. CSS loading/parsing is render blocking. By loading CSS that isn't needed immediately asynchronously in a way that will use the browser cache if it's available, it makes the page visible much faster. It feels like overkill in the simple example, but it's a tried and true method. ( https://github.com/filamentgroup/loadCSS has > 2k stars if that kinda thing means anything) From my experience on a large websit…
In a few hours, I'm launching a very large website that relies heavily on LoadCSS(). Page load times have been excellent in the pre-public phase, even though our critical styles contain a mountain of Autoprefixer-generated flexbox prefixes.
My understanding is that all of this will become an antipattern once we can support http/2. For today, however, it provides a very real performance boost.
Re: Google recommends inlining small CSS
#48var cb = function() { var l = document.createElement('link'); l.rel = 'stylesheet'; l.href = 'small.css'; var h = document.getElementsByTagName('head')[0]; h.parentNode.insertBefore(l, h); }; var raf = requestAnimationFrame || mozRequestAnimationFrame || webkitRequestAnimationFrame || msRequestAnimationFrame; if (raf) raf(cb); else window.addEventListener('load', cb); Seems like it's time for a defer attribute on .
Or, you know, put it at the bottom of the HTML since it will take 5ms between the moment where the browser receive and
Re: Google recommends inlining small CSS
#49This makes perfect sense for classes like ".article51_footer_wrapper_margin50", look up the rule, and sure enough it looks like `.article51_footer_wrapper_margin50 { margin-bottom: 50px; }` Seriously, just inline rules like that. If it is only applied in one specific place across the entire site either because it cannot or does not need to be made more general, then inlining it is easier to maintain and understand.
Note that TFA is about using a style tag rather than a separate CSS file. It actually discourages the style attribute.
But TFA justifies avoiding the attribute because it "often leads to unnecessary code duplication" which is irrelevant "if it is only applied in one specific place across the entire site". It also mentions CSP as a reason to avoid the style attribute; can anyone explain what this means? Is this actually going to have a practical effect, and what does an inline style attribute have to do with security policy?
Re: Google recommends inlining small CSS
#50The problem i've always had with this, and the "above the fold" rule as it appears in the pagespeed insights tool, is the definition of "fold" varies wildly. So I see CSS optimisation as a multi-step process. * Switch to a component-based rendering architecture (I favour React) * Map CSS rules directly to components (I use CSS Modules) * Have a JavaScript entry-point per route. The entry-point should only contain wha…
I fear that we're on the verge of an era of 'fold-sniffing'. Actually, there are plenty of examples of annoying 'lazy-loading' scripts that defer image loading until images are visible, which just result in loads of stuttering page scrolls, waiting for images to appear. If I'd wanted an annoying interuption-filled streaming experience, I'd be watching netflix, not browsing your website...