Здравствуйте, eustin, Вы писали:
E>Ну может конечно) Но я когда отключал ресурсы на CDN замерил pagespeed / gtmetrix... и стало не хуже. E>И не понятно все же зачем CDN нужен страница грузится, потом JS отложенно грузится, все равно ведь с CDN или нет... потом картинки отложенно грузятся. CDN тут никаким боком не ускоряет. Только тратит порядка 50ms на соединение. E>Но может на днях затещу что будет, если CDN вернуть.
Не сомневайся, бородач точно пурну несет.
Сейчас есть время ответить тезисно.
1. "Сервер надо располагать ближе к клиенту и CDN не нужен"
У меня англоязычные клиенты идут со всего мира, основной трафик США, Англия, Австралия. Где по его мнению мне разместить сервер?
2. "На подключение к CDN уходят дополнительные 60мс"
А на обращение к моему серверу с другого конца света уходит 300мс.
Можно просто посмотреть в любой метрике waterfall чтобы увидеть выигрыш.
3. "З адинамическим контентом CDN будет постоянно обращаться к вашему серверу"
Этот специалист по хай-лоад не знает как правильно настроить кеширование?
4. "Это все заговор маркетологов"
На который ведуться все технологические гиганты. Они же ведь тупые, по определению.
Что касется твоего случая — какой протокол используется и из какой точки идет измерение?
rp5>А ты замерь из разных точек: Австралия, Бразилия, Корея, Япония. rp5>И еще сравни Калифорнию, Техас и Нью-Йорк. И сразу поймешь. rp5>Ну и попробуй файл хотя бы 20 МБ скачать из этих мест.
Я ж писал раза 2, дистрибутивы у меня на CDN, тут все понятно. Я про бесполезность CDN для JS/CSS/Картинок на сайте.
Сейчас используется Amazon, он ест баксов $200 месяц, все руки не дойдут затестить его против DigitalOcean за $5, стоит ли он того.
По тестам с Digital Ocean чуть медленне качается из США и России пробовал.
Спасибо! Видимо еще протестирую с CDN, посмотрю/подумаю. Хотя не все тут однозначно
I>1. "Сервер надо располагать ближе к клиенту и CDN не нужен" I>У меня англоязычные клиенты идут со всего мира, основной трафик США, Англия, Австралия. Где по его мнению мне разместить сервер?
I>2. "На подключение к CDN уходят дополнительные 60мс" I>А на обращение к моему серверу с другого конца света уходит 300мс.
Просто CDN же не поможет уменьшить время обращения (CloudFront так точно), если только CloudFlare. Я пробовал вешать CloudFlare на свой сервер и не заметил разницы в баллах GooglePagespeed и GTMEtrix.
По крайней мере проблема, TTFB о которой я изначально писал, не ушла.
I>Можно просто посмотреть в любой метрике waterfall чтобы увидеть выигрыш.
Вот мои тайминги Litehouse, https://s.mail.ru/5MTy/i5QaRzKDb
видно, что LCP наступает до загрузки любых скриптов и картинок. CDN действительно только замедлит все. Ну может Time To interact в теории уменьшится... но оно вроде как не входит в Web Vitals.
I>3. "З адинамическим контентом CDN будет постоянно обращаться к вашему серверу" I>Этот специалист по хай-лоад не знает как правильно настроить кеширование?
I>4. "Это все заговор маркетологов" I>На который ведутся все технологические гиганты. Они же ведь тупые, по определению.
Когда стоит задача максимально быстро загрузить сайт с кучей тяжелых картинок высокого разрешения, с CDN лучше.. Но если задача получить зеленую зону WebVitals и допустима подгрузка картинок по мере скролла, допускаю что cdn не нужен.
I>Что касается твоего случая — какой протокол используется и из какой точки идет измерение?
HTTP 1. Я пока не осилил обновить основной сервер с ubuntu 16, который не поддерживает http2. Точнее поднял для тестов новый сервер с ubuntu 20 на http2 у того же Digital Ocean... и не заметил прироста никакого на том же сайте. Все основные тайминги те же.
Ну и говорят http 1 лучше на медленных соединениях и иногда проигрывает http2.
Мне изначала смутило предупреждение PageSPeed о недопустимом TTFB (600ms). Меряет соответственно Гугл. https://s.mail.ru/H4Zv/Vti2VkGKr
Когда я мерею со своего браузера из РФ, сейчас показывает TTFb 200ms. Вот пытаюсь понять, реально уменьшить TTFB. Оно ведь зависит от сервера и кэширования а не от cdn.
Вообще моя главная задача, получить в SearchConsole зелененькие линии в Основные Интернет показатели https://s.mail.ru/Lkxq/UtAv8xSTQ
E>Спасибо! Видимо еще протестирую с CDN, посмотрю/подумаю. Хотя не все тут однозначно
Ну смотри — гугл бот открывает с одной скоростью, причем всегда разная, потому что он везде(в каждой стране).
Хром пользователей открывает с другой скоростью по всему миру разная.
Вопрос — что возьмет Гугл за основу? НЕ там копаешь.
F>Вопрос — что возьмет Гугл за основу? НЕ там копаешь.
Ок, на днях врублю cdn для теста... но я ж за web vitals борюсь, в частности за LCP (в консоли именно с ним проблемы)... а оно вследствие оптимизации наступает ДО загрузки картинок и скриптов, которые на cdn.
Здравствуйте, eustin, Вы писали:
E>Сейчас используется Amazon, он ест баксов $200 месяц, все руки не дойдут затестить его против DigitalOcean за $5, стоит ли он того. E>По тестам с Digital Ocean чуть медленне качается из США и России пробовал.
судя по отзывам производительность DO Spaces CDN отвратительная
Здравствуйте, eustin, Вы писали:
E>Просто CDN же не поможет уменьшить время обращения (CloudFront так точно), если только CloudFlare. Я пробовал вешать CloudFlare на свой сервер и не заметил разницы в баллах GooglePagespeed и GTMEtrix. E>По крайней мере проблема, TTFB о которой я изначально писал, не ушла.
И CloudFlare и CloudFront являются CDN. Разница будет видна только с разных локаций. Например, сервер в США, а тестирование из Австралии.
TTFB — time to first byte или время ответа сервера. Никакая отложенная загрузка тут не помогает, это время до загрузки вашего HTML кода, а он у вас не в CDN.
E>видно, что LCP наступает до загрузки любых скриптов и картинок. CDN действительно только замедлит все. Ну может Time To interact в теории уменьшится... но оно вроде как не входит в Web Vitals.
у вас все страницы динамически меняются? кешируйте и закидывайте их в CDN
E>Когда стоит задача максимально быстро загрузить сайт с кучей тяжелых картинок высокого разрешения, с CDN лучше.. Но если задача получить зеленую зону WebVitals и допустима подгрузка картинок по мере скролла, допускаю что cdn не нужен.
если у вас пинг до сервера 300мс, то КАЖДЫЙ элемент страницы будет ожидаться 300 мс, а с CDN только изначальный HTML код
E>Мне изначала смутило предупреждение PageSPeed о недопустимом TTFB (600ms). Меряет соответственно Гугл.
у меня даже нет на странице показателя TTFB, похоже слишком мал
E>Когда я мерею со своего браузера из РФ, сейчас показывает TTFb 200ms. Вот пытаюсь понять, реально уменьшить TTFB. Оно ведь зависит от сервера и кэширования а не от cdn.
в Search Console меряет не Google, а Chrome на машинах ваших посетителей
т.е. у большинства ваших посетителей пинг до вашего сервера в DO 600мс либо сервер слишком тормозит
E>В TTFB входит резолв DNS, соединение по https, ответ Апача и исполнение скриптов на сервере, пока Апач не начнет слать. Вот никак не пойму как это все оптимизировать ) E>Хочется именно попугаи, которые PageSpeed мерит, в зеленую зону с моим ttfb не выйти
У меня TTFB 612 мс, сайт в зелёной зоне (PageSpeed 99%, Gtmetrix 96%), хостинг на reg.ru. Может, дело не в TTFB?
Кстати, PageSpeed мне пишет "Reduce unused JavaScript" и указывает на /gtag/js?id=XXXX(www.googletagmanager.com). Имеется в виду, что гугловский таг скрипт является unused?
I>И CloudFlare и CloudFront являются CDN. Разница будет видна только с разных локаций. Например, сервер в США, а тестирование из Австралии. I>TTFB — time to first byte или время ответа сервера. Никакая отложенная загрузка тут не помогает, это время до загрузки вашего HTML кода, а он у вас не в CDN. I>у вас все страницы динамически меняются? кешируйте и закидывайте их в CDN
Конечно, сайт на php. В том то и проблема, что CloudFront — только статика. А CloudFlare я пробовал, правда только для .ru сайта, но Pagespeed с ним по прежнему ругался на 600ms TTFB. Наверно попробую для основного.
PHP вообще нужен — цены динамические делать по ip адресу, комментарии и рейтнги в базе данных хранить (с кэширование в файловой системе конечно), пользователей на емейлы подписывать (важно), выдавать ключи по всяким акциям, и еще всякое по мелочи... не думал даже о том, чтобы все в статике хранить)) а вы правда так делаете?
да и обновления сайта усложнятся, неужто нельзя достичь нормальных показателей на обычном хостинге)) ngix как вариант пробовать и менять провайдера. Хотя кто-то тут писал что у него на Digital Ocean все ок.
I>если у вас пинг до сервера 300мс, то КАЖДЫЙ элемент страницы будет ожидаться 300 мс, а с CDN только изначальный HTML код
Я кидал watermarll, до LCP вообще нет ресурсов никаких, все заооптимизировано. CSS inline, картинки и скрипты грузятся после события Page Loaded, в первой области отображения под мобильные нет картинки.
I>у меня даже нет на странице показателя TTFB, похоже слишком мал
вот да...
I>в Search Console меряет не Google, а Chrome на машинах ваших посетителей I>т.е. у большинства ваших посетителей пинг до вашего сервера в DO 600мс либо сервер слишком тормозит
Предупреждение о 600ms вроде как относится к тесту в реально времени, а не к статистике, оно при каждом тесте чуть меняется.
Посмотрел в Аналитиксе, походу да, проблема в индусах.
Здравствуйте, eustin, Вы писали:
E>Конечно, сайт на php. В том то и проблема, что CloudFront — только статика. А CloudFlare я пробовал, правда только для .ru сайта, но Pagespeed с ним по прежнему ругался на 600ms TTFB. Наверно попробую для основного.
все приличные CMS генерят статику
E>PHP вообще нужен — цены динамические делать по ip адресу, комментарии и рейтнги в базе данных хранить (с кэширование в файловой системе конечно), пользователей на емейлы подписывать (важно), выдавать ключи по всяким акциям, и еще всякое по мелочи... не думал даже о том, чтобы все в статике хранить)) а вы правда так делаете?
да, статика лежит в Memcached и ее забирает nginx напрямую, скрипты дергаются только когда кеш протух
разумеется, есть динамические страницы, но их меньше 10% на сайте
E>да и обновления сайта усложнятся, неужто нельзя достичь нормальных показателей на обычном хостинге)) ngix как вариант пробовать и менять провайдера. Хотя кто-то тут писал что у него на Digital Ocean все ок.
у меня все на DO, но смотрю в сторону Amazon, по цене различия примерно в 2 раза для моего сайта
E>Я кидал watermarll, до LCP вообще нет ресурсов никаких, все заооптимизировано. CSS inline, картинки и скрипты грузятся после события Page Loaded, в первой области отображения под мобильные нет картинки.
так с CDN у вас все к тому моменту успеет подгрузиться
E>Предупреждение о 600ms вроде как относится к тесту в реально времени, а не к статистике, оно при каждом тесте чуть меняется. E>Посмотрел в Аналитиксе, походу да, проблема в индусах.
у меня в PageSpeed все отлично, а в Search Console появляются оранжевые страницы регулярно
E>Их почти в 2 раза больше, чем Американцев и у них время загрузки 6 сек против 1,7 американцев.
Здравствуйте, 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 ним).
Если используете Google Tag Manager (GTag), выпилите его. Не смотря на то, что Page Speed Insights жалуются на TTFB и в графике Performance LCP происходит до скриптов, в реальности GTM — причина тормозов страницы.
У меня сайт целиком в CDN. Для редкозапрашиваемых страниц Page Speed жаловались на большой TTFB: т.к. страница не в кеше, ответ был долгим. Но причина была не в этом. Нужно избавляться от лишних скриптов. jQuery я так же выпилил, но эффект как от GTM не было.
Здравствуйте, chebum, Вы писали:
C>Здравствуйте, 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 ним).
C>Если используете Google Tag Manager (GTag), выпилите его. Не смотря на то, что Page Speed Insights жалуются на TTFB и в графике Performance LCP происходит до скриптов, в реальности GTM — причина тормозов страницы.
C>Заменил GTag на старый скрипт analytics.js и стало намного лучше: https://imgur.com/0bVRNBC
C>У меня сайт целиком в CDN. Для редкозапрашиваемых страниц Page Speed жаловались на большой TTFB: т.к. страница не в кеше, ответ был долгим. Но причина была не в этом. Нужно избавляться от лишних скриптов. jQuery я так же выпилил, но эффект как от GTM не было.
У меня все с точностью до наоборот было — jQuery сильно тормозил.
Можно не выпиливать а отложенно грузить JS, тогда показатели норм.
Интересно, что сейчас все в зеленой зоне и показатели 99% для обоих версий сайта, но гугл упорно кажет в репорте оранжевым кучу страниц с которыми тапа надо поработать.
Сдается мне что программисты гугла опять нарукожопили что-то в алгоритмах либо то, как они измеряют скорость сильно далеко от идеала.
C>Заменил GTag на старый скрипт analytics.js и стало намного лучше: https://imgur.com/0bVRNBC C>У меня сайт целиком в CDN. Для редкозапрашиваемых страниц Page Speed жаловались на большой TTFB: т.к. страница не в кеше, ответ был долгим. Но причина была не в этом. Нужно избавляться от лишних скриптов. jQuery я так же выпилил, но эффект как от GTM не было.
GTag у меня грузится спустя 1,7 секунд после события PageLoad, что позволяет его исключить из Pagespeed.
Я таки добился зеленой зоны в Search Console. Пришлось CloudFlare повесить. Походу проблема была в индусах и прочих странах подобных.
Здравствуйте, autopsist, Вы писали:
A>Интересно, что сейчас все в зеленой зоне и показатели 99% для обоих версий сайта, но гугл упорно кажет в репорте оранжевым кучу страниц с которыми тапа надо поработать. A>Сдается мне что программисты гугла опять нарукожопили что-то в алгоритмах либо то, как они измеряют скорость сильно далеко от идеала.
это не программисты, а твои посетители виноваты
для тебя все быстро, а для африканских аборигенов с диалапом — медленно
Здравствуйте, icezone, Вы писали:
I>Здравствуйте, autopsist, Вы писали:
A>>Интересно, что сейчас все в зеленой зоне и показатели 99% для обоих версий сайта, но гугл упорно кажет в репорте оранжевым кучу страниц с которыми тапа надо поработать. A>>Сдается мне что программисты гугла опять нарукожопили что-то в алгоритмах либо то, как они измеряют скорость сильно далеко от идеала.
I>это не программисты, а твои посетители виноваты I>для тебя все быстро, а для африканских аборигенов с диалапом — медленно
страница грузится, потом JS отложенно грузится, все равно ведь с CDN или нет... потом картинки отложенно грузятся. CDN тут никаким боком не ускоряет. Только тратит порядка 50ms на соединение.
