А кто-нибудь знает как уменьшить time to first byte до <200ms с текущих 600ms? https://s.mail.ru/3qWQ/Lkin2KkXY
Хостинг если что Digital Ocean, $55/m, SSD. Редиректов нет, DNS от Амазона. Все что можно в настройках Апача вроде перепробовал.
Такой же ttfb выдается на голом html, без php скриптов, так что дело не в них.
Кроме как накатить nginx с кэшем идей нет (не хочется связываться c ним).
TW>Это какая-то ерунда TW>От Москвы до США пинг ~150ms TW>ДО ближних стран намного меньше
TW>Попингуйте ваш сервер
В TTFB входит резолв DNS, соединение по https, ответ Апача и исполнение скриптов на сервере, пока Апач не начнет слать. Вот никак не пойму как это все оптимизировать )
Хочется именно попугаи, которые PageSpeed мерит, в зеленую зону с моим ttfb не выйти
ЕМ>А эти "наблюдения" соответствуют истине? Что говорят всякие live tester'ы?
Кстати, да не сообразил.
Gtmetrix говорит TTFB=345, уже лучше Хоте советуют вроде не более 200ms все равно. https://s.mail.ru/eYd3/tg2Esro93
Connect: 246ms
Backend: 99ms
Походу connecting зависит от хостера, backend — от Апача и скриптов..
Видимо надо хостера другого пробовать (246ms)... но вроде DigitalOcean популярен весьма.
Хочется Core Vitals в зеленой зоне.
Здравствуйте, eustin, Вы писали:
E>А кто-нибудь знает как уменьшить time to first byte до <200ms с текущих 600ms? E>https://s.mail.ru/3qWQ/Lkin2KkXY E>Хостинг если что Digital Ocean, $55/m, SSD. Редиректов нет, DNS от Амазона. Все что можно в настройках Апача вроде перепробовал. E>Такой же ttfb выдается на голом html, без php скриптов, так что дело не в них. E>Кроме как накатить nginx с кэшем идей нет (не хочется связываться c ним).
Дык а что Digital Ocean говорит?
Я бы посоветовал не полностью доверять гугловской измерялке, ибо она явно еще не отлажена.
На пример у нас есть проект, на котором усрененные данные за 28 дней всегда чуть ли не в идеале, а текущие всегда с замечаниями. И есть наоборот.
Лучше мерять разными тулзами...
Здравствуйте, eustin, Вы писали: E>Такой же ttfb выдается на голом html, без php скриптов, так что дело не в них. E>Кроме как накатить nginx с кэшем идей нет (не хочется связываться c ним).
Здесь думаю дело в чем-то другом. У меня сервер на DO в NYC2, из Нью-Йорка TTFB 25ms.
ЧВ>Здесь думаю дело в чем-то другом. У меня сервер на DO в NYC2, из Нью-Йорка TTFB 25ms. ЧВ>Как меряете? Где сервер? Где клиент?
О, спасибо, буду знать, что на DO это возможно
Сервер в NYC2 тоже. Мерил соответственно PageSpeed и GTMetrix...
Может в моем первом посте это не очевидно, PageSpeed ругается на TTFB https://s.mail.ru/zAna/dKTJueNU9
Search console в желтой зоне. https://s.mail.ru/Sci7/qNaZsaqwo
Ну и в Pagespeed в предупреждениях всегда весит TTFB, видно не с проста.
Текущий Дроплет на старенькой Ubuntu 16, php7... Я уже успел поднять новый для теста в Sun Francisco на Ubuntu 20 на том же DO, TTFB тот же
Прикручивание http2 не помогло...
A>Дык а что Digital Ocean говорит?
Напишу в поддержку, на их форуме нашел другие жалобы на TTFB
A>Я бы посоветовал не полностью доверять гугловской измерялке, ибо она явно еще не отлажена. A>На пример у нас есть проект, на котором усрененные данные за 28 дней всегда чуть ли не в идеале, а текущие всегда с замечаниями. И есть наоборот. A>Лучше мерять разными тулзами...
Понял, спасибо. Буду еще смотреть Google Analytics, вроде в нем точная статистика есть. Просто подозреваю Pagespeed именно при ранжировании используется..
Здравствуйте, eustin, Вы писали: E>О, спасибо, буду знать, что на DO это возможно E>Сервер в NYC2 тоже. Мерил соответственно PageSpeed и GTMetrix... E>Может в моем первом посте это не очевидно, PageSpeed ругается на TTFB
По этим скринам не очень понятно откуда производится измерения. Если из России, там и 600 мс может быть легко.
Пинг Moscow-NY это где-то 120мс, те как минимум столько на DNS, плюс обмен тремя TCP пакетами при хендшейке, плюс SSL session setup.
Например я (клиент) в Австралии, сервер в NYС2, можно курлом потестить:
curl -o nul -w "Connect: %{time_connect} TTFB: %{time_starttransfer} Total time: %{time_total} \n" "https://www.softperfect.com"
Connect: 0.250000 TTFB: 0.953000 Total time: 1.172
Попробовал из NYC1 в NYC2 получил:
curl -o /dev/null -w "Connect: %{time_connect} TTFB: %{time_starttransfer} Total time: %{time_total} \n" "https://www.softperfect.com"
Connect: 0.082808 TTFB: 0.108105 Total time: 0.1086
Попробуйте у себя тоже с NYC1 в NYC2, если цифры больше значит проблема в Апаче или VPS.
Здравствуйте, eustin, Вы писали:
E>А кто-нибудь знает как уменьшить time to first byte до <200ms с текущих 600ms?
Воткнуть перед приложение Amazon CloudFront или Cloudflare.
ЧВ>Попробуйте у себя тоже с NYC1 в NYC2, если цифры больше значит проблема в Апаче или VPS.
Спасибо... Померял с того же хоста (localhost)
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 157k 0 157k 0 0 216k 0 --:--:-- --:--:-- --:--:-- 216k
Connect: 0.136 TTFB: 0.722 Total time: 0.726
Connect: 0.019 TTFB: 0.457 Total time: 0.468
Connect: 0.067 TTFB: 0.297 Total time: 0.301
Это я сделал несколько змерений.
Походу дело в Апаче или хостинге... Но на другом дроплете те же цифры были + у вас все ок на DO.
Буду ковыряться дальше. Саппорт накидал шаблонных ссылок на их гайды не очень по теме.
E>>А кто-нибудь знает как уменьшить time to first byte до <200ms с текущих 600ms? C>Воткнуть перед приложение Amazon CloudFront или Cloudflare.
CloudFlare попробовал, не помогло, даже чуть больше стал TTFB по PageSpeed.
А CloudFront это же CDN, от него давно отказались. Только для билдов оставили, для статики он не нужен говорят), это еще одно подключение, оно только увеличит TTFB.
На сколько я изучил тему, CDN — это вообще маркетинг и развод на деньги. CSS надо инлайнить, картинки lazy load-ить, js не критичные грузить с задержкой.
Здравствуйте, eustin, Вы писали:
E>На сколько я изучил тему, CDN — это вообще маркетинг и развод на деньги. CSS надо инлайнить, картинки lazy load-ить, js не критичные грузить с задержкой.
CloudFront и CloudFlare позволяют кэшировать данные как можно ближе к потребителю.
Например, у нас приложение работает в us-east-1 (на восточном побережье США), до которого пинг около 60 миллисекунд, но благодаря CloudFront, ресурсы скачиваются менее чем за 10 миллисекунд из местного кэша.
Возможно, это не работает для России из-за того, что нет точек присутствия CloudFront и CloudFlare поблизости.
C>Например, у нас приложение работает в us-east-1 (на восточном побережье США), до которого пинг около 60 миллисекунд, но благодаря CloudFront, ресурсы скачиваются менее чем за 10 миллисекунд из местного кэша.
Не надо путать скачивание ресурсов и TTFB Если сайт на php, то CDN не спасет, даже наоборот
Вот видео на тему: https://www.youtube.com/watch?v=nsvzaDlVU98
А ресурсы не должны влиять не только на TTFB, но даже на FCP т.к. они должны lazyloadиться / инлайниться / отложенно грузиться.
Я в итоге отказался от картинок, скриптов и CSS на CDN и Pagespeed на сколько я помню, стал лучшую оценку давать.
Сейчас только билды остались на нем, чтобы быстрее качались. И то периодически для теста врубаю CDN DiigtalOcean Spaces, которая стоит $5 в отличие от сотен долларов в месяц от Амазона... пока к сожалению а/б тест не получилось полноценный сделать.
I>ой, зря ты этого "спкциалиста" слушаешь, он же пургу несет
Ну может конечно) Но я когда отключал ресурсы на CDN замерил pagespeed / gtmetrix... и стало не хуже.
И не понятно все же зачем CDN нужен страница грузится, потом JS отложенно грузится, все равно ведь с CDN или нет... потом картинки отложенно грузятся. CDN тут никаким боком не ускоряет. Только тратит порядка 50ms на соединение.
Но может на днях затещу что будет, если CDN вернуть.
E>Но может на днях затещу что будет, если CDN вернуть.
У меня сервак, когда nginx а еще не было тормозил. Думаю выложу на CDN игры и разгружу сервак.
Но всплески внезапного ботовского трафа на CDN оставили без трусов.
Здравствуйте, eustin, Вы писали:
E>Ну может конечно) Но я когда отключал ресурсы на CDN замерил pagespeed / gtmetrix... и стало не хуже.
А ты замерь из разных точек: Австралия, Бразилия, Корея, Япония.
И еще сравни Калифорнию, Техас и Нью-Йорк. И сразу поймешь.
Ну и попробуй файл хотя бы 20 МБ скачать из этих мест.
Хоте советуют вроде не более 200ms все равно.
