Google recommends inlining small CSS

251 点作者 jayfk超过 9 年前

33 条评论

lewisl9029超过 9 年前

This is probably not a very good general recommendation, but inline CSS actually makes quite a bit of sense to me when using React/Redux.Style is generally heavily interconnected with app state in modern web apps, so why not take advantage of a sophisticated state management system like Redux to declaratively manage your styles along with your state rather than adding/removing class names at runtime imperatively? With React's implementation of inline-styles, you can treat your styles as just another piece of JS data in your state tree, and have the entire power of the JS language at your fingertips to compose/extend/manage them, including powerful functional transformations, a flexible and statically analyzable module system, and prototypical inheritance, if you're into that kind of thing.With this approach, you completely remove any need for preprocessors, get rid of a whole class of CSS limitations like the lack of a proper module system, and global scoping and the associated specificity issues, and your components become truly self-contained by default.That said, I don't have a lot of actual experience with this approach in practice, so I definitely could be missing some nuances and practical limitations. I'd love to hear some opinions/experiences regarding using inline styles in React/Redux.

评论 #10889257 未加载

评论 #10889770 未加载

评论 #10888980 未加载

radarsat1超过 9 年前

This is the part that surprised me,> Further, inline CSS on HTML elements is blocked by default with Content Security Policy (CSP).I'm probably not up to date on this stuff, since I am not a web dev, but does this mean it's actually not possible to use `style=""` in your HTML elements any more? I thought it was not recommended, but more for organizational reasons, not security reasons. What is the reason?

评论 #10887297 未加载

yoz-y超过 9 年前

I do not understand this particular example. They replace 4 lines of external CSS + 1 line of loading by 1 line of internal CSS + 2 lines of tags + 11 lines of JavaScript which then asynchronously loads 3 lines of CSS.So we went from a blocking call and 5 lines of code to 17 lines and an async call. How is this in any way better than simply cramming the 4 lines of CSS internally? Maintenance will not be simpler because you will still probably have several rules to maintain over several files (and the inlining can be automated).This seems like horrible over-engineered advice _especially_ for small CSS files.

评论 #10887795 未加载

评论 #10887283 未加载

losvedir超过 9 年前

Interesting. The sample code includes this bit:<pre><code> var raf = requestAnimationFrame || mozRequestAnimationFrame || webkitRequestAnimationFrame || msRequestAnimationFrame; if (raf) raf(cb); else window.addEventListener('load', cb); </code></pre> 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 gotten used to using jQuery's `$(document).ready(..)` which as far as I know uses DOMContentLoaded or window.onload behind the scenes. When does the first animation frame happen in relation to those callbacks?

评论 #10886872 未加载

评论 #10887028 未加载

评论 #10886682 未加载

andrewingram超过 9 年前

The 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 what's needed for that route, common bundles can be used too (I use webpack for this).* Have equivalent CSS entry points per route (again, Webpack).* On initial (ie server) render, render a style tag into the document that contains the content of the relevant entry CSS. By definition this is very close to being only the CSS required for that page (if your components have various different classes depending on config, there may be some bloat here, not sure if there's a workaround).* On that same render, don't include an external reference to the actual stylesheets. (At this point we're mimicking Google's advice)* On first client-side navigation (yeah, i'm assuming you're using client-side routing), load the required stylesheets for the destination URL, remove the style tag, then continue the navigation.I'm actually excited, because in the React ecosystem, we're not too far removed from this entire process being relatively trivial to implement. I'm assuming other ecosystems are similar.

评论 #10886799 未加载

评论 #10886698 未加载

oliwarner超过 9 年前

> If the external CSS resources are smallIt's not a general rule, it's just suggesting that your 50 character block of CSS (that might be dynamic or conditional) would be better off as part of the main markup than a separate request and all the overhead associated with that.If your static CSS exists in lots of small files, you would strongly benefit from rolling them together.Both these recommendations may change with new delivery models (ie HTTP2).

评论 #10886333 未加载

评论 #10886298 未加载

aexaey超过 9 年前

Offered example is missing this in the "you can inline" snippet:<pre><code> <head> <noscript> <link rel="stylesheet" href="small.css"> </noscript> </head> </code></pre> ..least whole point of this excercise is to make life a little bit more miserable for those pesky users who dare to disable js.

评论 #10887251 未加载

评论 #10887269 未加载

johnsbrayton超过 9 年前

I agree that Google's recommendation here is a poor one in most cases.It would be better to do the following:1. Have only one or two external CSS files per page.2. Serve CSS compressed when possible.3. Ensure that CSS does not require any server-side processing or compression, that the server just spits out a .css or .css.gz file when the CSS is requested.4. Ensure that the CSS files are relatively small.5. Serve the CSS files with a very long cache time and with a version/hash string in the object name.6. If feasible, make CSS changes relatively relatively rare.If you do all of these things, adding the style into the web page will clutter your HTML and slow things down for frequent visitors. Yes, it might also increase perceived performance for some users who have not visited the site since the last change to the CSS.

评论 #10887766 未加载

cbr超过 9 年前

You can automate this with the prioritize_critical_css filter in the PageSpeed module: <a href="https://developers.google.com/speed/pagespeed/module/filter-prioritize-critical-css" rel="nofollow">https://developers.google.com/speed/pagespeed/module/filter-...</a>(Disclaimer: this is what I work on.)

DanielBMarkham超过 9 年前

Over 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 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.In much the same way, in FP you can just make it work, then generalize, then group, then eventually create modules/classes full of generalized functions. This way of thinking seems to result in far quicker execution and far less complexity. Not sure if it translates to CSS, though. It'll be interesting to try it out.

评论 #10886626 未加载

评论 #10887586 未加载

评论 #10887000 未加载

blowski超过 9 年前

This 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.

评论 #10886490 未加载

评论 #10886565 未加载

评论 #10886410 未加载

PavlovsCat超过 9 年前

Are there any findings about whether such godawful class names affect rendering performance? I mean just matching strings such as this one:com-google-api-explorer-client-history-EmbeddedHistoryItemView_HistoryItemUiBinderImpl_GenCss_style-showHideHeadersIt's generally really hard for me to take HTML advice from google seriously, their page sources at best look mediocre, and at worst they make my eyes bleed. How can code so complicated lead to such bland looking pages? I know I'm kind of being snarky, but I can't help it. Just look at the source of that page and the linked stylesheets, look at google.com, heck, if you can find me just one elegant page I'll be grateful, because to this day I haven't seen a single one.

评论 #10886436 未加载

评论 #10886646 未加载

评论 #10886534 未加载

fkooman超过 9 年前

I love how they, in that example, use JS to load the rest of the CSS. Seriously?

评论 #10886482 未加载

评论 #10886453 未加载

pkorzeniewski超过 9 年前

I remember a CSS class in some enterprise software I was working on several years ago:<pre><code> /* bold */ .bold { font-weight: bold !important; } </code></pre> It has became my favourite real-world example of CSS misusage :)

评论 #10886853 未加载

评论 #10886741 未加载

评论 #10887734 未加载

评论 #10887577 未加载

评论 #10886864 未加载

评论 #10887719 未加载

ars超过 9 年前

Note they mean inlining the css rules in a <style> block.Not inlining the css as the style attribute of a tag.The goal is not to have to fetch a second css page.

评论 #10886424 未加载

mozumder超过 9 年前

If you have single-page web apps, you might as well inline your entire site's CSS, since it's never going to look for the CSS again.

评论 #10886420 未加载

评论 #10888631 未加载

评论 #10887890 未加载

评论 #10886427 未加载

eCa超过 9 年前

<pre><code> <script> var 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); </script> </code></pre> Seems like it's time for a defer attribute on <link>.

评论 #10886761 未加载

jsvaughan超过 9 年前

if you use the google pagespeed apache/nginx module it has an inline_css filter which does this for you, no need to cause yourself a maintenance problem.

Nutmog超过 9 年前

Whatever happened to the programming rule of don't micro-optimize until you've measured the performance? There seems to be a lot of recommendations to do ugly things to websites in the name of optimization, but they still add complications that are hard to understand. Pictures used to by supposed to be optimized by pre-scaling them to the size they'd be displayed at. Now we have retina displays and that doesn't work anymore. You have to do more complicated things instead. HTML and co has become very low level-like and almost complex enough that perhaps humans shouldn't be doing it. It reminds me of the days of assembly language and all the ugly little tricks to squeeze out more clock cycles that are now handled by compilers.

评论 #10888510 未加载

3princip超过 9 年前

Which mandates 'unsafe-inline' if you're using a content security policy (CSP).>Banning inline script is the biggest security win CSP provides, and banning inline style likewise hardens your application.[1]So which is it? Should we be moving away from inline scripts and CSS, and tightening it up with CSP, or is performance/fewer requests more desirable? Also, with HTTP2, the performance issue seems moot.[1]<a href="http://www.html5rocks.com/en/tutorials/security/content-security-policy/" rel="nofollow">http://www.html5rocks.com/en/tutorials/security/content-secu...</a>

JoeSloth超过 9 年前

I'd also like to throw this into the conversation:Inline styles also prevent the user from overriding styles with a custom style sheet (think color blind people). This isn't necessarily against ADA/508 compliance, but it should be taken into consideration.

评论 #10889016 未加载

theandrewbailey超过 9 年前

I think that this is the wrong way for most websites to do CSS, as it contradicts both minimization+concatenation and HTTP2 best practices. If you have just one CSS file that's heavily cached and 100 KB (because you base64ed your webfonts to reduce request count), you should be fine.Just last night, I tested trying to separate out my fonts from my CSS. Google Pagespeed Insights still threw a fit over no async CSS, even though the CSS was 5 KB. FFS, Goog! I decided against that madness.

coverband超过 9 年前

OK, so this part is new to me:Don't inline CSS attributesInlining CSS attributes on HTML elements (e.g., ) should be avoided where possible, as this often leads to unnecessary code duplication. Further, inline CSS on HTML elements is blocked by default with Content Security Policy (CSP).How effective is this, really? If I can inline a CSS class, then I can inject any style on any HTML element even if I can't inline an attribute. Am I missing something here?

评论 #10889942 未加载

drinchev超过 9 年前

I think this Google rule is too specific and in the same time too general for being alive.The whole idea :> Inline small CSS.is too specific. I think when you work on a huge web-application you don't want to create such a bloat in your layouts and personally I don't think that this approach scales. On the other hand if you go with a simple web page, like a landing page with a couple of elements ... go for it.> If the external CSS resources are smallWhat is "too small" anyway ? ( too general )

NetStrikeForce超过 9 年前

(Disclaimer: I'm not a coder, so I easily get overwhelmed by what others might see as very simple)It may be better for delivery, but the second example is unreadable compared to the clean one. I can see why it's much better to add 15KB to your HTML file than having to request those 15KB from a separate file (one or two full round-trips of added latency :)).

评论 #10886473 未加载

bl4ckdu5t超过 9 年前

I think this has been for a long time now and I expect to see everyone speak about how this is a bad recommendation. If the above-the-fold content can extracted with a gulp/grunt plugin and injected it gets even better. These are extreme measures needed for performance profits and anyone can choose to take them or simply ignore

jakobegger超过 9 年前

Sometimes I wonder, if you can make the content above the fold load instantly, why can't you do that for the whole page?

评论 #10888002 未加载

Lanari超过 9 年前

Google's point here is to load a header really fast, the user will get this feeling that some progress happened, JavaScript will load the rest of the CSS after, while the rest of the page is getting loaded/rendered...Still, I won't use their method.

frabcus超过 9 年前

We inline the front page CSS on <a href="https://pdftables.com/" rel="nofollow">https://pdftables.com/</a>, both for user experience and for SEO reasons.The Node module UnCSS (<a href="https://github.com/giakki/uncss" rel="nofollow">https://github.com/giakki/uncss</a>) is working reliably for us, using PhantomJS to automatically extract the CSS rules we need for our front page.The full CSS rules are then loaded at the end of the page - just in case UnCSS missed a browser specific or Javascript triggered rule, and to get the files into the cache.

jlebrech超过 9 年前

is there a tool that'll find all the style attributes and compile those into a css file?

VOYD超过 9 年前

#AlphaBetFail - teach people how to do it correctly, teach them not to hack stupid ass inline CSS styles from 1996.

LoSboccacc超过 9 年前

that suggestion has been around for a while

评论 #10886733 未加载

noumandeaf超过 9 年前

the makes perfect same talk does need the is search hacker very like power you help me pleasei am nouman deaf