Let's take some CSS properties and place them randomly in our CSS file:
outline
pseudo-elements
Color Properties
Background and Border Properties
Box Properties
Flexible Box Layout
Text Properties
Text Decoration Properties
Font Properties
Writing Modes
Table Properties
Lists
Animation
If you want to maximize rendering speed, in what order should you list your CSS properties?
The short answer is: it doesn't matter.
To elaborate on that: Say you would implement a browser1 and get to the part where you parse CSS. How would you do that? Well, there is a grammar of CSS, so you use that to tokenize the stylesheet, build an AST and parse the stylesheet. This approach means that you would need to read everything2 before you can start to actually interpret the stylesheet. That is, apply the selectors to your DOM (also something you parsed, but from the HTML source instead of the CSS) and then apply the rules to elements matching those selectors. Note that everything we are doing so far is only modifying state of our data structures. We store on our elements what they should look like.
When that is done, the layout phase can begin (and with modern CSS, that is even harder thanks to flexible box and grid layouts). It sounds simple: calculate where every element will end up on the page. It's not, but suppose that we are great programmers with a thorough understanding of the specifications that we need to adhere to, so we can do this. What do we need to know? Well, all rules that apply to all elements. It's as simple as that. We cannot calculate a layout to then learn from the parser that "oh wait, I forgot, this element all the way at the start of the HTML source is in fact positioned absolutely, so you should start over with your positioning". So, we need to have processed everything in the stylesheet. The order in which we learned about the rules does not matter.
As if that is not enough, the next phase for our browser would be to draw everything, which again is nontrivial. Are you excited about building your own browser yet? 😉
If you are really interested in how the major browsers implemented all of this, you can have a look at their engines. I am not familiar with those at all, but I know that they are... intimidating.
So, ye be warned.
• Chrome (Chromium) uses Blink (source code, forked from WebKit).
• Edge uses EdgeHTML (forked from Trident).
• Firefox uses Gecko (source code), but is working on a new engine called Servo (source code).
• Internet Explorer uses Trident.
• Opera uses Blink (used Presto before Opera 15).
• Safari uses WebKit (source code).
I included links to source code as much as I could, but some browser engines are proprietary. The source of Presto was leaked some time ago, but I won't link to that here. You may be able to find it.
Disclaimer: I merely scratched the surface of building a browser. I haven't discussed interactivity, implementing a JavaScript engine, making HTTP requests, debugging tools, GUI design and implementation, et cetera.3 Building a browser is merely used to have a story in this answer. If you are actually interested in building a browser, consider these great resources4 don't. Rather, contribute to the development of your favorite browser, if it is open source!
Want to read more?
• This Mozilla Hacks article has a nice explanation of how a rendering engine roughly works.
It also includes pretty drawings!
____________________
1 You don't want to do that. Seriously. It's a lot of work. But, say you would.
2 Except maybe if you would be willing to work with the AST while it is built. But that is hard and error prone. It also won't gain you much in the end, as we'll see later.
3 That is discussed in a little more detail in this Mozilla Hacks blog post.
4 There never were any, you don't need to check the revision history of this post. It's just a joke.
Sorry if you find it a lame one.