Ben Darlow recently wrote a great article "Cargo Cult CSS", which has a quote from me in it, talking about performance. It's a quote from an old article (a few years ago now) which only half applies these days. I thought I'd update my thoughts on this …
Aside: HTML/CSS should be written for comprehension of the content.
For me, the goal of well written HTML is to tell me what type of content is being marked up and what role that content fulfils in the context of the page – without needing to read the content itself (if it exists at all yet). That's why I use class names and identifiers based on the content role, and not something superficial like how it appears to the eye.
The benefits seem obvious when I come to maintain that code, or apply a design on top of it, or parse it out in some other format, or need to manipulate it with JS, or a bunch of other things. It also helps me write better (more understandable and flexible) CSS and JS. I've written about this before, but to be frank it was a years ago that I last wrote about this, so you're better off reading Ben's article as it closely follows my own thinking and is more up-to-date. With regard to mark-up, there are numerous alternative methodologies which may suit you better. SMACCS, BAM, etc.
Back on topic: What you're optimising
When we 'optimise', we mean to optimise for performance. My advice in the past has been to ignore this aspect of HTML/CSS. The fact of the matter was that browsers are, and have been for a long time, very efficient at parsing HTML and CSS. You could write some pretty 'inefficient' code and the performance penalty you paid would be largely imperceptible to the average website visitor. So, it made no sense to 'optimise' your HTML/CSS for performance beyond authoring it well for comprehension – spend your time on things that matter orders of magnitude more; like crushing images and reducing HTTP requests.
That's still largely true; with one exception, which is becoming more and more important…
Optimising for interaction and animation
As soon as you're animating, or performing design changes triggered by interactions (hover effects, scrolling etc) – especially on mobile devices – you do need to audit your HTML/CSS for performance. People blame JS for making websites slow… most of the time JS is not the problem, it's the interaction or animation itself. It didn't used to matter too much, but with the modern habit of having transitions between state changes (as opposed to old-school binary effects) it's become much more noticeable when things start to get janky, stuttery, and slow.
Do yourself a favour and familiarise yourself with exactly how a browser works to generate a page's visuals; watch this entertaining and informative video… A Rendering Performance Guide for Developers
By the time you've finished you should understand why websites with parallax scrolling are the perfect storm of HTML/CSS performance problem, and that the problem really is the HTML and CSS. You might then want to watch this video to see how you can go about fixing those problems (where possible)… Performance Tooling