Да работать то оно будет, просто зачем двойную работу то делать? Сначала апатч сжимает, потом nginx разжимает и опять сжимает.
Решил протестить отключение сжатия на Apache сервере в файле .htaccess так называемого модуля mod_deflate.c т.к. говорят смысла нету, но как я и предполагал лично для моего странного сервера это плохой совет, уж не знаю почему, ни хочу никого обидеть, но после отключения сжатие пропало…
Проверка по команде:
curl -H "Accept-Encoding: gzip" -I www.vk.com
Не выдала Content-Encoding: gzip, а ранее выдавало.
Сайт для проверки сжатия а-ля gidnetwork.com выдал:
Web page compressed? No
Compression % 0.0
До этого:
Web page compressed? Yes
Compression % 70.3
Ну и в инструментах разработчика браузера по циферкам в колонке Size (Хотя там непонятно, некоторые были типа сжатые.).
Это у меня связано с моими методологиями разработки – вроде все работает не трогай | если решился настраивать, то давай ломай все до конца, переверни верх дном, сравняй с землей | принцип сапера, отрезаем аккуратненько по одному проводку ( Шутка ).
Я сейчас отключу сжатие в Apache, а потом окажется что оно не работает, или как-то не так работает или не полностью работает, а поисковые системы скажут ууу братан у тебя сжатия нет в 2020 году, иди-ка ты вниз к любителям без сжатия :), пусть лучше они вместе там сжимают и разжимают :) ( Шутка ).
И как я понимаю это уже тоже не актуально и можно убрать:
# Запрещает сжатие ответа методом gzip для IE6gzip_disable "msie6";
Вопрос у меня упрощается до уровня что лучше: 2.2 Ghz или как у РЕГ.РУ – тариф Высокочастотные серверы 3.7 Ghz – 5 Ghz с Turbo Boost или как у Timeweb – тариф HighCPU 5ГГц речь о Turbo Boost там вообще не идет как я понял.
По циферкам и логике должно быть в два раза быстрее, в реале я не знаю, может жуткая бессмысленная переплата не за что. Но, господа из РЕГ.РУ заявляют официально до 40% производительнее, а господа из Timeweb говорят +65% к производительности ядра.
