5

What are some best practices for writing memory-efficient (for the lowest peak memory usage) CSS? I realize this is a broad question, so I have broken it down into two main categories:

  1. What are 'do's and 'don"t's regarding which CSS properties should be used for what things in what circumstances for the smallest memory usage?
  2. Are there any 'evil' CSS properties (or classifications of CSS properties like [Please note that the following text contains a random supplementary example that is absolutely not a statement, only an example] the flexbox-related properties) that should be avoided at all costs?

I am creating a project-oriented website where users will be able to create projects with millions of items (DOM nodes) in them, so computer resources have the potential to be scarce.

In response to Caleth's concern of not specifying what CSS memory efficiency means, I will explain what CSS memory efficiency means in the context of this question. CSS memory efficiency refers to reducing the amount of memory CSS has caused the browser to consume for merging (when an element has the same CSS property set more than once, usually in more than one place), drawing, painting, flow-calculating, remerging (when new CSS is thrown into the mix, or old CSS is pulled out), redrawing, reflowing, and thrashing (in the event of the unforeseen) the DOM. In this context, it does not refer to the memory taken up to downloading the web page, rather it is strictly client-side. Nor does it refer to the efficiency of CSS selectors (I can already find plenty of articles on both those two).

  • 1
  • Who's memory? The client, the server? Peak or average usage? What are the other constraints on the system? – Caleth Jul 7 '17 at 9:11
  • "like the flexbox-related properties" This is vague by the way. The big thing about why flex gets slow can be related to nesting in the DOM not necessarily the CSS on individual nodes. It requires rather expensive DOM traversal is all when used in certain ways. You'd probably be better off testing ideas and profiling. The layout engine between browsers differs a lot. There are a number of nested DOM edge cases for say Firefox that have no issue in Edge or Chrome. – Sirisian Jul 7 '17 at 21:38
  • @Sirisian what you are saying is true, however please actually read the surround context instead of skimming the text for something to comment on. Flexboxes were used as a random example, not as something that I was stating as a fact. Also, I am holding out hope that there might be some article written by the programmers of a webbrowser in some dark corner of the internet about performance instead of being left to my own devices. – Jack Giffin Jul 7 '17 at 21:57
  • @lolzerywowzery Have you looked at using IndexedDB and generating DOM on the fly as the user navigates? (Or are all 1 million DOM nodes visible at once?) I've seen the architecture of a few project that displayed multiple large tables with ~100K records that use this with great results to be responsive. – Sirisian Jul 7 '17 at 23:16

protected by gnat Dec 30 '17 at 16:25

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Browse other questions tagged or ask your own question.