Как проверить скорость ответа хостинга напрямую

Пишут что у них, Beget и еще на нескольких росхостингах органы какой-то новый тип СОРМ поставили, черный ящик как его называют, он похоже сырой под нагрузкой вносит сетевые задержки. Но это слухи, а официально они будут все отрицать.

ТСПУ  это называется.

Вы что-то путаете. Стандартно он показывает данные в реальном времени всегда (сервис - ваш сайт).

И если доступны доп.данные накопленные, тогда показывает и их.

На некоторых серверах бегета с начала февраля время отклика увеличилось до 6 секунд, даже на статике. Сужу по своим сайтам и сайтам знакомых. Проблема не постоянная, то норм, то задержки. При этом даже по фтп попасть на сервер можно с трудом, а скачать- передать со скоростью 2кб/с. ТП бегета проблем не видят)).

мне сказали что это все CloudFlare тормозит. Хотя я его выключал и без него та же задержка.

Смотрите. Отклик от сервера >1 секунд для шаред хостинга это довольно распространённое явление. 

В принципе, надо хорошо понимать за что вы борeтесь и какая у вас цель. Если вы борeтесь за цифры, то вы занимаетесь перфекционизмом.

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

Когда FCP <1 секунды - это оптимально, это круто.  Такие результаты достигают наиболее оптимизированные сайты и реализовать такой результат обычный вебмастер для насыщенного сайта вряд ли может.

Время до 3 секунд - считается обычным, здесь как раз работают многие бесплатные CMS, впрочем и платные тоже.

Время после 3 секунд уже критическим - вот здесь зона в которой уже надо принимать решительные действия.

Так вот. Первый вариант явно не про вас, потому как у вас TTFB >1 секунды, а если по результатам измерений у вас FCP до 3 секунд, то волноваться вам не за что. Таких сайтов большинство и они нередко занимают топовые позиции.

Если вы в 3-ей зоне - надо разбираться и принимать меры.

Далее  TTFB зависит не только от физических возможностей сервера, но также и от вашей программной обвязки. На это значение влияет общая скриптовая часть, кол-во запросов к базе банных и т.д. Если вы просто вебмастер, который поставил WP и играется с плагинами, то на ваши возможности управлять этой областью данных весьма ограничены. Вы можете ставить лишь всякие "кэшеры и ускорители", но они тоже работают лишь по своим заданным алгоритмам.

Чтобы проводить оптимизацию более низкого уровня надо залезать в программную архитектуру, тестировать отдельно программные компоненты, по возможности их выключать, если они не нужны (без потери функциональности), менять порядок их загрузки и т.д. Это уже совсем другой уровень компетенции и качественно иной подход. 

Хороший специалист, который в этом разбирается и можем помочь это  LEOnidUKG  

Если вы готовы на этот шаг, напишите Леониду, возможно он согласится вам помочь. 

Но если вы не готовы менять уже сложившуюся функциональность, то по части программных кондиций вы ничего глобально не измените, в этом случае ищите более скоростные хостинги (а для этого их всё равно придётся тестировать) и используйте выделенный сервер. Но опять-таки к конкретной производительности вашего ПО, который мы сами собрали на WP вы никуда не уйдете, поэтому конечно не надо рассчитывать на топовые показатели, где вы не готовы вносить программные изменения (а это может быть долго и недёшево). 

Адекватность ТП - это отдельная тема. Нередко ТП не будет сильно погружаться в специфику клиента, а иногда у того, кто вам отвечает просто не хватает опыта, чтобы дать вам качественно полезный совет. 

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

Дальше, как уже сказал выше, готовы идти глубже - закажите технический программный аудит. Вам протестируют компоненты движка отдельно и укажут, что именно создаёт ненормированную нагрузку, посоветуют заменить/убрать/модернизировать какой-то отдельный компонент, а вот только потом можно применять различные "кэшеры и ускорители", объединяющие скрипты, css, и прочие технологии которые выполняют кэш плагины.

Лечение CMS нередко надо проводить изнутри, а не снаружи 😉