LESS / SASS CSSの「プリプロセッサ（呼ばれていると思いますか？）」は、縮小化などの最適化とは逆であると言えますか？パフォーマンスに目立った影響があるのでしょうか？それとも、開発のしやすさがより重要だと思いますか？
LESS CSSが生成するものは次のようなものなので、私はこれを尋ねます
body #div1 #div2 p
body #div1 #div2 p a:link, body #div1 #div2 p a:visited
...
そして、それは私のCSSをかなり膨らませることができると思います。ご覧のとおり、このような特異性は必要なく、CSSの読み取りが難しくなります（少なくともfirebugで見られるもの）。
Sassでは、ネストがどのように機能するかを理解することで、「特異性の肥大化」を制御できます。必要がなければ、ネストを行う必要はまったくありません。これは、制御できるものです。
新しい@extendディレクティブを使用すると、 OOCSSの原則を適用することで、CSSの冗長性を実際に減らすことができ、パフォーマンスを向上させることができます。@extendを使い始めるのに役立つ記事があります。そして、さらにいくつかのOOCSSリソース：
Sassでの@extendの大きな利点は、OOCSSの適用に手作業が必要であり、非常に簡単で簡単なことです。
最後に、Andreaが指摘したように、SassにはCSSを縮小するためのさまざまなオプションがあります（：compressedスタイルを参照）。したがって、全体として、開発者としてのパフォーマンスを向上させるだけでなく、パフォーマンスを向上させるための非常に強力なツールキットが実際にあります。あなたのCSSの。この動作の例については、Compassの作成者でSassの主要な貢献者であるChris Eppsteinが、Diggスタイルシートを125行のコードから85行のコードにリファクタリングする方法を参照してください（32％削減）。
驚かれることでしょうが、コードのブロックが繰り返されているgzipで圧縮されたCSSファイルは、セレクターが短いファイルよりも大きくなりすぎないようにする必要があります。
これは、圧縮アルゴリズムがファイル内の重複する文字列を処理する方法のおかげです。同じ文字列を2回含める代わりに、2番目の文字列を最初の文字列への参照に置き換えます。これにより、文字列は圧縮ファイルに1回だけ表示されます。生成されたCSSファイルのセレクターがどれほど反復的であるかを見てください。これにより、セレクターがかなりうまく圧縮されるはずです。
当然、これの鍵は、CSSファイルがgzipで圧縮されていることを確認することです。圧縮しないままにしておくと、ファイルサイズが確実に大きくなります。
オプションに応じて、SASSはさまざまなスタイルで出力を提供できます。本番環境では、出力スタイルを「コンパクト」に設定する必要があります。
物事を読みやすくするためのsass用のfirebugアドオンがあります。とにかく、出力を直接読み取る必要はありません。
Sass、less、xCSSはより多くの出力を生成しますが、私はそれを肥大化とは呼びません。
手書きのCSSは、多くの冗長性と重複があり、コードのライフサイクル中に開発者が名前空間を他の名前空間の上に重ねると、すぐに劣化します。ソフトウェアの保守、設計、または作成が不十分な場合の症状の1つは、膨満感です。また、CSSには最初から設計上の欠陥があるため、最高のCSSコーダーでさえこの制限の影響を受けます。
そのため、適切にフォーマットされたsass / lessファイルの初期フットプリントと、数回編集された手書きのCSSファイルを比較検討する必要があります。
sassのもう1つの利点は、HTMLがスリムになることです。CSSのフラットでグローバルな構造を補うために、コード全体にクラス名を追加する必要はありません。