Сам я использую W3 Total Cache - функциональности на порядок больше.

если по производительности, то угнаться за WP Super Cache в режиме Mod_Rewrite не может ни один плагин кэширования для вордпресса. к сожалению, он работает далеко не так прозрачно, как Hyper Cache - я его тестировал, он там постоянно плодил файлы кэша чуть ли не для каждого посетителя отдельно. плюс сброс кэша в нем достаточно кривой - кэш сбрасывается для отдельных посетителей, полная же очистка кэша идет по расписанию. в итоге получается, что плагин постоянно что-то удаляет и заново создает. как итог - страницы отдаются максимально быстро, но вот нагрузка на дисковую систему сервера может положить весь сервер, особенно на крупном сайте с десятками тысяч страниц.

вот и получается, что чем проще плагин кэширования - тем он лучше. для рядового блога Hyper Cache идеальный вариант.

Не замечали ли вы он под одну кешируемую страничку один файл создает?

конечно один. в статье есть скрин из ftp-клиента - там эти странички в архивированном виде видны. строго один файл под одну страничку.

Sape или тому подобными системами продажи ссылок?

да легко. ставьте таймаут кэшированных страниц в 720 и это вполне достаточно. объясню немного - бот сапы обходит сайты 2 раза в сутки. следовательно, если при первом обходе новые ссылки и выпадут в Error, то уже при втором обходе статус будет OK. таким образом ни одна error-ссылка не протянет больше 12 часов. конечно, ссылки постоянно будут выпадать в error - новые и unsleep, но на самое короткое возможное время.

и сокращать время таймаута кэшированных страниц нет никакого смысла - все равно рано или поздно бот попадет на кэшированную страницу, где еще не разместилась новая ссылка. так что 720 минут в данном случае самое оно.

как обстоит с совместимостью плагина и вордпресса 3,5?

Совместимость с версией WordPress: 2.5 и выше.

автор плагина достаточно активен и часто обновляет плагин, так что никаких сюрпризов с несовместимостью не будет.

0.57314 seconds => 0.00033 seconds

а как вы протестировали время? ведь при кэшировании отдается уже сгенерированная страница, а время генерации первоначальной страницы остается таким же.

Выбор стоит между Hyper Cache и скриптом MaxSite Cache.

последний это упрощенная версия Hyper Cache. работает он чуть быстрее, но только за счет того, что функций в нем и проверок на порядок меньше. я бы не стал тратить деньги на плагин, чей более продвинутый аналог есть в бесплатном варианте.

как взаимодействуют плагины кеширования с такими элементами как соцкнопки, рейтинг Postratings и др?

социальные кнопки это по сути js-скрипты, а поэтому они прекрасно будут работать и на кэшированных страницах и всегда будут показывать правильную информацию. а вот с плагинами типа рейтингов будут проблемы - они отображают информацию, которую берут из базы данных. в кэшированном варианте такие плагины обращаются к базе данных только в момент кэширования и соответственно не отображают актуальную информацию. собственно, выход только один - или отказаться от подобных плагинов, либо установить таймаут кэшированных страниц в 1 сутки - тогда хоть раз в сутки информация будет обновляться на актуальную.

собственно, в этом и беда кэширования - динамику он убивает напрочь и именно поэтому многие блоги обходятся без плагинов кэширования.

по поводу различных баннерных и рекламных сетей - если код вызова рекламы сделан на js-скриптах (как яндекс директ, гугл эдсенс и тд), то кэширование выводу актуальной рекламы никак не помешает.

Ошибка 330 (net::ERR_CONTENT_DECODING_FAILED). Как решить ее?

полагаю, что ошибка в том, что ваш сервер неправильно работает со сжатием. отключите в настройках плагина отдавать браузеру сжатые файлы. не поможет - отключите сжатие вообще.