css 页面加载中
For several years now we’ve been hearing this. That somehow magically “moving style out of your external stylesheet and into the markup” makes the page “render faster”. Whilst unlike the bald faced LIE that is “classes are better than selectors and combinators” it’s not a total work of fiction, in most practical applications it does come across as a mix of ignorance and wishful thinking. Even if Google PageSpeed Insights or Pingdom claim otherwise.
几年来，我们一直在听到这一点。 以某种方式神奇地“将样式移出外部样式表并移入标记”使页面“渲染速度更快”。 尽管光秃秃的LIE不同于“选择器和组合器更好”，但这并不是虚构的全部，在大多数实际应用中，它的确是无知和一厢情愿的结合。 即使Google PageSpeed Insights或Pingdom另有声明。
真实的部分 (The Part That’s True)
If raw benchmarking and testing a single page cache-empty, putting the style for everything that might land “above the fold” (aka fits on the screen) static into a <style> tag does result in the page styling that result first. There’s no arguing that. You get to a “First Meaningful Paint” faster because the browser’s not waiting on that second file.
如果原始基准测试和测试单个页面为空，则将可能“超出首屏”(也就是屏幕上适合)的所有样式的样式都静态地放置在<style>标记中，这样会首先导致页面样式化。 没什么可争辩的。 您可以更快地进入“第一个有意义的画图”，因为浏览器没有在等待第二个文件。
但是，实际上整体速度更快吗？ 长期？ (But Is It Actually Faster Overall? Longterm?)
If you look closely at how it is tested, and the premise of it, you may notice a flaw. It only applies to cache-empty first-load. Whilst sure, you only get one chance to make a first impression, you are likely making every page request after that slower!
如果仔细查看它的测试方式和前提，您可能会发现一个缺陷。 它仅适用于高速缓存为空的首次加载。 可以肯定的是，您只有一次获得第一印象的机会，但您发出的每个页面请求的速度都可能会变慢！
And that’s the flaw. If you have a high traffic site where users check in regularly and view multiple different pages, it should be about more than just that first-load! That’s a problem you see a lot in development where one single datapoint or focus drowns out the bigger picture. A lot of site owners are falling into such a trap with their sites due to the use of things like Lighthouse. A very handy tool indeed, but not every single data point should be taken as the Gospel! Hell, most people don’t even treat the Gospel as the Gospel, why are these things suddenly inviolate?
这就是缺陷。 如果您的网站访问量很高，用户可以定期签入并查看多个不同的页面，那么它应该不仅仅是首次加载！ 这是一个在开发中经常看到的问题，其中单个数据点或焦点淹没了全局。 由于使用了诸如Lighthouse之类的东西，许多网站所有者都陷入了他们网站的陷阱。 确实是一个非常方便的工具，但并非每个数据点都应该当作福音！ 地狱，大多数人甚至不把福音当成福音，为什么这些事情突然变得不合时宜呢？
Bottom line is that this technique makes all your other pages consume more bandwidth and take longer to load.
最重要的是，这项技术会使您所有其他页面占用更多带宽，并且加载时间更长。
等等，什么？！？ 如何使其他页面变慢？ (Wait, What?!? How Is It Making Other Pages Slower?)
Because they too need a copy of mostly the same CSS. At least assuming the pages share the style for things like headers, footers, menus, borders, colouration, etc, etc.
因为他们也需要大多数相同CSS的副本。 至少假设页面共享页眉，页脚，菜单，边框，颜色等的样式。
As such not only does putting the same style into every user request slow down pages, it’s a failure to exploit caching!
因此，不仅将相同的样式放到每个用户请求中都会减慢页面速度，而且利用缓存是失败的！
Again, you’re sending extra code on EVERY pageload, which means you’re not caching that extra data! Even if it’s the same page if it isn’t caching due to frequent updates, you just missed a caching opportunity. By not leveraging caching and forcing a reload of style, you make all the subpages load slower, you’re increasing the server load, etc, etc.
同样，您将在每个页面加载上发送额外的代码，这意味着您不会缓存这些额外的数据！ 即使由于频繁更新而没有进行缓存，即使是同一页面，您也错过了缓存机会。 通过不利用缓存和强制重新加载样式，可以使所有子页面的加载速度变慢，服务器的负载增加等。
就像框架和演示性标记 (Just Like Frameworks and Presentational Markup)
It’s the same bleeding edge HTML 3.2 1990's mentality — are an epic fail at using HTML or CSS properly. The same reason that code like this:
这与HTML 3.2 1990的思路相同，这是正确使用HTML或CSS的重大失败。 像这样的代码的相同原因：
<p class="if ig fq ih b ii ij ik il im in io ip iq ir is it iu iv iw ix iy iz ja jb jc fi cp">Or this:
或这个：
<input class="bg-white focus:outline-none focus:shadow-outline border border-gray-300 rounded-lg py-2 px-4 block w-full appearance-none leading-normal" type="email" placeholder="jane@example.com">Or this:
或这个：
<a class="w3-bar-item w3-button w3-padding-large w3-hide-medium w3-hide-large w3-right" href="javascript:void(0)" onclick="myFunction()" title="Toggle Navigation Menu">Or even this:
甚至这样：
<div class="d-flex flex-column flex-md-row align-items-center p-3 px-md-4 mb-3 bg-white border-bottom box-shadow">..are why “frameworks” and “presentational classes” are monuments to developer ignorance, incompetence, and ineptitude. You’re pissing on the markup with presentation, something that has ZERO BLASTED BUSINESS IN YOUR HTML IN THE FIRST FLIPPING PLACE!
..为什么“框架”和“代表阶级”是开发人员无知，无能和无能的纪念碑。 您在演示文稿上加了标记，这在第一个翻转位置使HTML中的业务零爆炸了！
You end up moving and placing presentation into the markup. This results in larger markup, slower parsing markup, slower loading markup, and a failure to cache across page-loads. It’s a pointless sacrifice for the “synthetic” first-load cache empty ideal, that neglects every other aspect of sane and rational development!
您最终将演示文稿移动到了标记中。 这将导致更大的标记，更慢的解析标记，更慢的加载标记以及无法跨页面加载进行缓存。 对于“合成的”首次加载缓存为空的理想，这是毫无意义的牺牲，而忽略了理智和理性发展的所有其他方面！
那么它在哪里工作？ (So Where Would It Work?)
- “Squeeze Pages” and other small single page sites prone to high levels of bounce, and “one visit per customer” “挤压页面”和其他小的单页面站点倾向于出现高水平的跳出，并且“每位客户一次访问”
SPA’s (Single Page Applications). Note, given how the implementation of most SPA’s is 100% JavaScript reliance, the accessibility and usability /FAIL/ of that makes them something that shouldn’t exist in the first place.
SPA(单页应用程序)。 请注意，考虑到大多数SPA的实现是100％JavaScript依赖的，因此/ FAIL /的可访问性和可用性使它们一开始就不应该存在。
它在哪里失败？ (Where Does It Fail?)
- Forums 论坛
- Blogs网志
- Shopping购物
- Medium, Quora, Hashnode, anyplace else where people visit multiple pages or revisit frequently.中型，Quora，Hashnode，以及人们访问多个页面或经常访问的其他任何地方。
人们为什么盲目相信并应用到任何地方？ (Why Do People Blindly Believe It and Apply it Everywhere?)
Well there is merit and truth in the argument for it; but a lot of mental failings and a good deal of lack of self reliance are the root of it. That’s not meant to insult people, it’s more a factor of how the brain is wired and how certain things easily bypass rational thought. That’s how propaganda techniques work, and why they are involved, intentionally or not. For example:
好吧，论据中有优点和真理。 但很多精神上的失败和大量缺乏自力更生是其根源。 这并不是要侮辱人，而是决定大脑如何连接以及某些事物如何轻易绕开理性思维的一个因素。 这就是宣传技术的工作方式，以及为何有意或无意地参与其中。 例如：
卡堆叠 (Card Stacking)
Omitting any facts — like the impact on total bandwidth and server overhead — that conflict with the claim. Even when unintentional it’s painfully common for people to do this, dismissing, omitting, or outright attacking anything that opposes their pre-established viewpoint.
忽略任何与声明冲突的事实，例如对总带宽和服务器开销的影响。 即使是无意的情况，人们这样做仍然很痛苦，无视，遗忘或直接攻击任何与他们既定观点相反的东西。
感言 (Testimonial)
But… it worked for my site! But this bigwig at Google said it works. Anecdotal at best, and one of the most common techniques for bypassing rational thought.
但是...它对我的网站有用！ 但是谷歌的这位大佬表示，它行得通。 轶事充其量是一种绕开理性思考的最常见技巧。
闪闪发光的一般性 (Glittering Generalities)
“Oh but it’s faster this way.” Really? When? “Oh but it’s easier”… Really? How? The best way to recognize these is to ask questions like where, when, how. If they stumble, flounder, and then go “because it is” or “because I said so” its a good indication you’re being packed full of manure.
“哦，但是这样更快。” 真？ 什么时候？ “哦，但是更容易”……真的吗？ 怎么样？ 认识这些的最好方法是问一些问题，例如在哪里，何时，如何。 如果它们绊倒，挣扎，然后“因为是”或“因为我这么说”而去，这很好地表明您的粪便已被塞满。
I could go on for some time about the other four major propaganda techniques — transfer, plain folks, name calling, and bandwagon — but I’m going to save that for a future article because it’s a problem industry-wide. Instead, let’s focus on the mental failings.
我可以花一些时间讨论其他四项主要的宣传技巧-转让，普通人，姓名打电话和跟风-但我将其保存在以后的文章中，因为这是整个行业的问题。 相反，让我们专注于精神上的失败。
生存偏差，确认偏差和认知失调。 (Survivorship Bias, Confirmation Bias, and Cognitive Dissonance.)
“We did it and it worked!” “They did it and it worked!” Really? Compared to what?
“我们做到了，它奏效了！” “他们做到了，而且奏效了！” 真？ 比起什么？
When people get an answer that worked for them today — or more specifically appeared to work — they are very unlikely to be able to change their mind about it tomorrow even when it’s clearly failing. This is a constant woe in development as sooner or later people start blanket applying the wrong solution just because it “worked” for them before, even if it didn’t actually work. Developers become the proverbial carpenter with a hammer; suddenly everything looks like nails.
当人们获得今天对他们有用的答案(或更具体地看来有效)时，即使明天显然失败了，他们也不太可能改变主意。 随着人们迟早开始错误地应用错误的解决方案，只是因为它曾经为他们“工作过”，即使实际上并没有奏效，这也一直是开发中的祸患。 开发人员用锤子变成了众所周知的木匠。 突然，一切看起来像指甲。
And whilst you can drive a screw with a hammer — or as Uncle Red refers to it a “flathead screwdriver” — anyone with at least two working brain cells should realize how stupid an idea that is.
而且，尽管您可以用锤子打螺丝-或像雷德叔叔所说的那样是“一字螺丝刀”-但任何拥有至少两个正常大脑细胞的人都应该意识到这个想法有多么愚蠢。
I see this far too often working as an accessibility and efficiency consultant, where because clients — or more specifically their developers — got away with doing things in a wrong/incorrect way for years, they flat out refuse to believe the techniques they are using are wrong. They’ll dive for bandwagon saying “but millions of companies do it this way” dragging out a host of other lame excuses to try and get out of changing anything. Even when it’s costing them money, clients, and even in the face of ongoing fines and civil litigation.
我经常看到这样的情况是作为可访问性和效率顾问，在这里，因为客户(或更具体地说是他们的开发人员)多年以来一直以错误/不正确的方式来做事，所以他们坚决拒绝相信自己使用的技术在错误。 他们会追随潮流，说“但数百万公司这样做”，拖出了许多其他la脚的借口，试图摆脱任何改变。 即使在花费他们金钱，客户的情况下，甚至面对持续的罚款和民事诉讼。
See the mouth breathers who defend bootcrap, tailwind, react, vue, etc, etc even when it’s clearly why the company they are working for is in legal trouble.
即使为他们工作的公司遇到法律纠纷的原因，也要见识那些捍卫bootcrap，顺风，反作用，vue等之类的令人垂涎的呼吸器。
The same developers who will use tricks like this, obsess over minifying their code and relying on CSS pre-processors, end up flipping out utterly losing their composure if you even ask “hey, do you really need these six separate DIV with the dozen classes on each wrapping a lone H2 and paragraph tag?”.
同样的开发人员将使用这样的技巧，着迷于缩减代码并依赖CSS预处理器，如果您甚至问“嘿，您真的需要十几个类的六个独立DIV，最终会完全失去信心”每个包装上都有单独的H2和段落标签？”。
And that brings us to:
这使我们能够：
子弹伤口创可贴 (Band Aids on Bullet Wounds)
The real reason people go for these types of “fixes” is that they are unwilling to put in the time to fix the real problems. They’re stopgaps based on trying to laser focus on a single easy fix. This ghetto mentality “but we can’t redo it from scratch no matter how screwed up it is” is why amateurs grab duck tape, flex tape, super glue, chewing gum, bailing wire, or any other half-assed “fix” whenever something goes wrong.
人们选择这类“解决方案”的真正原因是他们不愿意花时间解决实际问题。 它们是基于试图将注意力集中在一个简单的修复上而制止的。 这种贫民窟的心态“但是无论如何拧紧，我们都不能从头开始重做”，这就是为什么业余爱好者会在任何时候抓住鸭胶带，软胶带，超级胶水，口香糖，吊索或其他任何半固定的“固定物”的原因出问题了。
That’s all these techniques are. They provide the ILLUSION of fixing the problem. Moving style into the markup, “classes for everything” — even CDN’s and caching services — are more often than not temporary stopgaps at best, placebos at worst. And rubes and nubes alike are suckered by them out of what Eisenhower once referred to as “Apathy, ignorance, and wishful thinking.”
这就是所有这些技术。 它们提供了解决问题的错觉。 将样式添加到标记中，“万事俱备”(甚至包括CDN和缓存服务)通常最多不过是暂时的障碍，最坏的时候是安慰剂。 艾森豪威尔曾经所说的“冷漠，无知和一厢情愿”从中吸取了很多东西。
那么什么才能真正使页面更快？ (So What Can Really Make Pages Faster?)
Using less markup by leveraging semantics, selectors, and combinators whilst removing presentational classes. Using less total CSS by not relying on any of those garbage frameworks. Not using JavaScript for things that don’t even need to be scripted! Maybe even use a monolithic stylesheet per media target so that you pre-cache the appearance of sub-pages on the user’s first visit.
通过利用语义，选择器和组合器来减少标记，同时除去表示类。 通过不依赖任何垃圾框架来使用较少CSS。 不使用JavaScript甚至不需要编写脚本！ 甚至每个媒体目标都可以使用整体式样式表，这样您就可以在用户首次访问时预先缓存子页面的外观。
Maybe, JUST MAYBE, if people stopped using 100k or more of HTML to do 16k or less’ job, 500k+ of CSS spread out over a half dozen files to do 48k or less in one file’s job, and megabytes of “JS for nothing” spread out over dozens of files on pages that might not even warrant the PRESENCE of scripting… well, maybe then they wouldn’t be diving for these types of stupid tricks.
也许，只是也许，如果人们使用100K以上HTML做16K以下职位，500K CSS传播+出超过半打的文件做48K或在一个文件中的工作越来越停止，‘白白JS’的兆字节在页面上散布了数十个文件，这些文件甚至可能都不保证脚本的存在性……好吧，也许那时他们不会为这些愚蠢的技巧而苦恼。
But no, most just layer fix upon fix, patch upon patch, until the whole thing is a bloated slow wreck. Then to try and fix it being slow and bloated, they think switching around the load order or throwing more code at it is the answer? Why, because PageSpeed Insights or Pingdom “Said so”? Ermagahd Aherpaderp!
但是，没有，大多数只是逐层修复，一次又一次修补，直到整个事情变得a肿缓慢。 然后，要尝试解决缓慢而and肿的问题，他们认为切换加载顺序或向其中加载更多代码是答案吗？ 为什么，因为PageSpeed Insights或Pingdom表示“如此”？ 埃尔玛格·阿赫帕德普！
I’ve lost track of the number of sites I’ve optimized for clients the past decade where the #1 problem with load time was due to megabytes of code in several dozen separate files doing the job of around 150k or less in only three or four files.
我忘记了过去十年中为客户优化的网站数量，其中加载时间排名第一的原因是几十个单独文件中的兆字节代码仅在三个或三个小时内就完成了大约150k的工作四个文件。
A situation made worse by a lack of proper understanding of HTML and CSS that leads to people using off the shelf templates that “look good” but are slow inaccessible wrecks, or dumbass bloated frameworks that claim to be “easier” or “better for collaboration” whilst delivering the exact opposite. Ever consider that you might not need 100k of HTML to deliver 8k of plaintext and three content images?
由于对HTML和CSS缺乏正确的了解，使情况变得更糟，导致人们使用现成的模板，看起来“不错”，但沉船速度缓慢，无法进入沉船，或者笨拙的框架自称为“更轻松”或“更好的协作” ”，而恰恰相反。 是否曾经考虑过您可能不需要100kHTML即可交付8k的纯文本和三个内容图像？
Throwing more code at it, or re-arranging what files certain pieces of code are in, server-caching services, content delivery networks, and so forth aren’t the answer if the underlying code is bloated trash.
如果底层的代码trash肿，扔掉更多的代码，或者重新排列某些代码片段在什么文件中，服务器缓存服务，内容交付网络等等都不是答案。
My God, man! Drilling holes in his head’s not the answer. The artery must be repaired. Now put away your butcher knives and let me save this patient before it’s too late. — Leonard “Bones” McCoy.
天哪！ 不能在他的头上钻Kong。 必须修复动脉。 现在收起您的屠夫刀，让我在为时已晚之前救救这个病人。 伦纳德·“骨头”麦考伊。
css 页面加载中
扫一扫
1519
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
