BREACH and CRIME don't compromise sites, because they are attacks on clients, not on servers. The server is still involved in that, for instance, TLS compression won't be used unless the server agrees; so that, even if the CRIME attack targets the client, the server can refuse to use compression and this indirectly protects vulnerable clients.
Both attacks relate to the same general principle: encryption hides data contents, but not data size. Compression makes data size dependent on data contents. Therefore, compression can leak information on data contents that encryption won't protect. If the attacker is in a position where he can inject some data of his own along with the data that he tries to recover (formally, a chosen-plaintext attack), then he wins.
CRIME was an application of this concept to TLS-level compression in a Web context. The Web allows for Javascript, that can be hostile and issue requests (subject to some constraints in the case of cross-site requests); this is how the attacker can achieve a CPA situation. Deactivating TLS-level compression fixes the issue, and it was not really fixable in any other way, because the compression-induced data leakage is a very generic concept. Note that HTTP-level compression does nothing for or against CRIME, since CRIME concentrates on the header (the request path and the cookie).
BREACH is another application of the concept, this time on HTTP-level compression. HTTP-level compression is performed only on request bodies, not on the HTTP headers, so BREACH is harder to pull off (while CRIME worked whenever a cookie was involved, BREACH requires the site contents to be amenable in some way to the attack). Disabling TLS compression will do nothing for or against BREACH.
Anyway, compression (be it for TLS or only for HTTP request/response bodies) will be applied by any machine only if it is reasonably sure that the machine at the other end of the connection will understand it -- because of some prior indication to that effect (in the TLS ClientHello
message for TLS, in a request header for HTTP). There will be no compression, hence no attack, unless both client and server support it and agree to use it. This is how mitigation for attacks on clients can be applied on the server.