А кто-нибудь знает как уменьшить 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 МБ скачать из этих мест.
Здравствуйте, 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>для тебя все быстро, а для африканских аборигенов с диалапом — медленно
Хоте советуют вроде не более 200ms все равно.
