Вроде простой вопрос, но в инете все очень расплывчато, типа 0.1 отлично, 1 сек хорошо, 10 сек плохо

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

А от объема не должно ли зависеть? Так то вроде есть тайм-аут 200-250 секунд.

для интерактивного сайта немного другие метрики

а ля время получения первого байта, время окончания отрисовки, время интерактивной доступности

(1) 1 кбайт

ну и вообще юзай реакт-вью. там подгрузка идет после отрисовки

(4) Ну так то не должно превышать миллисекунды

(6) а поконкретнее, например 0.18 сек это плохо или хорошо?

А какая  разница, что прилетает в ответ? html, json, xml или еще что-то? Как вообще мерять? Может пакет по дороге завис? Может сервер перегружен?(тогда причем здесь json? надо говорить просто об времени ответа сервера)

(7) Поконкретнее не должно быть больше тайм аута. Но для психологии пользователя не должно быть более 0.5 сек с отображением всей страницы.
Это уже чисто психологический вопрос и вопрос скорее загруженности - будут ли успевать отрабатываться все запросы к ресурсу и каков максимальный предел.

Народ так то терабайтами в сек. иногда данные получает. Так там даже сжатие примитивными алгоритмами позволяет получить прирост скорости в 20-30%.

(7) хорошо для чего?

(9) да практически никакой современный сайт за 0.5 сек не открывается

опишу более конкретнее.

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

сейчас у меня генерится json запрос к серверу каждые 3 секунды, ответ приходит за 0.2 сек, но например картинки скачиваются значительно дольше и с одной стороны хорошо-бы перейти на запрос каждую секунду, с другой стороны это будет уже приличная нагрузка на "сервер", примерно 25% времени на одну сессию.

зачем каждую секунду? может нужно на колбэках?

https://coderlessons.com/tutorials/kachestvo-programmnogo-obespecheniia/ruchnoe-testirovanie/testirovanie-vremeni-otklika

0,1 секунды -    Это наиболее предпочтительное время ответа. Если время отклика составляет 0,1, пользователи всегда чувствуют, что приложение или система реагируют мгновенно, и не испытывают никаких помех.

1,0 секунды -    Он определяется как максимальный предел приемлемого времени ответа. Пользователи вряд ли почувствуют какое-либо прерывание, хотя могут испытывать некоторую задержку. Время отклика более 1 секунды может прервать взаимодействие с пользователем.

10 секунд -    Это максимальный предел, после которого время отклика выходит за допустимый предел. Однако в настоящее время, если время ответа превышает 6 секунд, пользователь покинет этот сайт или выйдет из приложения.

--------------------------------------------------------------------------
но это с точки зрения пользователя, а мне хочется узнать с точки зрения промышленной эксплуатации

(12) нафига? переходи на вебсокеты

и с сервера пуш сообщения об изменениях

(16) да ну нафиг широковещательными засирать....
кроме того я не хочу давать исходящий доступ с "сервера" в основную сеть

(17) а раз в 1с пинать сервер - это значит нормально?

(18) да нормально, это гарантирует, что ситуация когда сервис упал сразу станет видна, это намного проще чем считать время между пушами

(17) вебсокеты - это не широковещательный

да и "исходящего" доступа там не будет

клиент коннетится к серверу по обычному http, но не разрывает соединение, а вызывает метод upgrade, результатом получается соединение для двустороннего обмена данными между клиентом и сервером по событиям

у меня счас аналог системы оповещения на 100 пользюков работает, достаточно активно юзается. по потреблению - 0% проца  и 50мб ОП. на ноде 14й

а какова цель запросов? а ля пинг или что?

(24) передача текущих значений (температура, время, ошибки, события)

(25) а зачем так часто то?

а мы уже приехали?

хотя может это какой критический процесс.
может он там плазму добывает для контролируемого термояда

(19) при разрыве вебсокета генерится сообытие в js

(23) все зависит от того как сервер сделан, может там в (12) база размером гигабайт без индексов и каждый запрос это fullscan...вот он и висит

пока вот так https://ibb.co/McxQ5p9

(0) Очень просто: Если у тебя ответ формируется путем сложных SQL-запросов по таблицам с многомиллионными записями и кучей джойнов, то приемлемо и минут 10, или даже пол часа, если задача сильно крутая.
Если там ничего важного нет, то ответ должен прийти за время, которое человек согласен подождать этот ответ. Короче, от важности и срочности зависит. Например, если запросил прогноз погоды на сегодня, то понятное дело никто не будет ждать минуту. Тут максимум несколько секунд должно пройти, а желательно меньше одной секунды.

(9) Понятное дело что отрисовка должна быть быстрая. Это вообще не связанные задачи. Например, пользователь отправил запрос перезагрузить сервер 1С. Ему сразу же на интерфейсе должно отрисоваться сообщение что запрос послан, и показать например песочные часы. Это все должно произойти очень быстро, без задержек. Но json-ответ о том что сервер перезагружен никто не ожидает что придет в ту же секунду. Пользователь понимает что это может занять минуты, и будет терпеливо ждать или пойдет пить чай. Вернется - а тут и json-ответ пришел что сервер завис и требует проверить диски на ошибки. Все довольны.

(0) Я бы ориентировался на таймаут браузера. Для ориентира лучше взять Safari, у него самый короткий таймаут из всех браузеров - 60 секунд.

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

Если что-то долго работает,то по хорошему,нужно показать исполнение процесса в виде ProgressBar, чтобы не было ощущения,что все зависло.
И,если данные сразу не готовы,то лучше за ними зайти потом,когда они будут готовы,чем ждать.
То есть,если в 0.1 секунды не уложились,то вернуть пользователю информацию,что данные готовятся и сходить за ними ещё раз.

(0) Нет понятия нормального времени, подходящего под все условия. Для сайтов в общем отлично - это 0.5 сек, хорошо - до 1 сек, приемлемо - до 2 сек. Но сказать что вот "в данном конкретном случае 1 секунда это нормально" нельзя. Нельзя сказать, что ТО машины стоимостью 100000 рублей это много: это много для среднестатистических людей, а для кого-то это нормально или даже мало. Если в твоей кастомной системе лично тебя время отклика устраивает, система при этом работает стабильно, то время будет нормальным, пусть оно хоть 10 секундам равно.

Отличный вариант до 100мс, если речь о UI. Промышленеые системы определяют требования по времени ответа. К примеру в рекламных  аукционах некоторые сервисы выставляют требования ответить за 20-30мс