超級快速，零實用性
　　我們知道ID’s 是最高效的選擇器。當你想讓渲染速度最高效時，你可能會給每個獨立的標簽配置一個ID，然后用這些ID寫樣式。那會超級快，也超級荒唐。這樣的結果是語義極差，維護難到了極點。即使在核心部分你也不應該見過這樣做的。我認為這個可以提醒我們不要為了高效的CSS放棄語義和可維護性。
　　實用性
　　還刻前面提到的Mozilla的一篇文章？已經有十年了。事實是：計算機比十年前變慢了。我感覺這東東在當年似乎還更受重視。十年前我還是個21歲的英俊小生，當然我不覺得那里我會認識css這東東。不管怎樣上面提到的東東都是有意義的，你可以按照上面的方法去做，因為它并不會限制你的CSS制作。但你也沒必要太教條主義。如果你是個完美主義者，而之前又沒有考慮過那東東，那是時候去重新看一下你之前寫的一些樣式是否有改進的地方了。如果你沒發現你的網站明顯的渲染緩慢，那大可別太在意，在以后的工作中多注意就行了。
　　從右到左
　　瀏覽器如何讀取你的CSS選擇器有一個很重要的原則，那就是它們從右到左讀取。這意味這像 ul > li a[title="home"] 這樣的選擇器，a[title="home"] 將是最先被讀取的。這一部分通常被稱為 “key selector”選擇器的最后一部分，也是被選擇的標簽。ID’s 是最有效率的，通用符是最慢的有四種目標選擇器：ID, class, tag和通用符。
　　一個選擇器渲染失敗比這個選擇器被渲染更高效
　　我不是很確定是否有更好的證據去證明這一點，因為如果你有大量的選擇器在CSS樣式表里無法找到，這樣的事情貌似很離奇，但一點必需注意的是，從右到左的解釋一個選擇器來說，一旦它找不到，那它就會停止嘗試。然而如果它找到了，那它就需要花更多精力去解釋了。
　　不要用標簽修飾
　　ID’s 是唯一的，所以不需要用標簽修飾，這只會讓它更低效。如果你可以避免的話，也不要用它修飾 class 。class 不是唯一的，所以理論上你可以把它用在不同的標簽。如果你愿意的話，你可以用標簽控制不同的樣式，這樣你可能需要標簽修飾（比如：li.first），但這樣做的人很少，所以，don’t .絕對沒有比用后代選擇器更糟糕的做法了