Кешировать js счётчиков/рекламных сетей и т.д.

Не думаю, что статистика после такого будет нормально работать.

Я тут пробовал через JavaScript ставить куки и сразу проверять их наличие. Если есть - выводить кнопки поделиться и комментарии ВК. Скорость стала такой, будто Гугл эти скрипты вообще не видит :)

работает нормально

в клубе я.метрики даже ответ был официальный несколько лет назад

Так а почему бы ей на работать? Какая разница откуда грузится файл? Главное регулярно его обновлять, чтобы скрипт соответствовал последней версии, выпущенной соцсетью, аналитикой или что там ещё грузится.

Хорошо, в этом есть смысл. Но всё же хочу уточнить:

а) где лучше размещать скрипты? Если есть возможность закачивать из на поддомен, то лучше туда или на основной домен?

б) если на сервере настроено кеширование js в браузере на 10 дней, а крон будет каждый час перезакачивать js статистики, рекламных и соц.сетей, то если в новозагруженном файле будут изменения, увидит ли их пользователь? Не хотелось бы, чтобы неправильно работала аналитика или реклама.

Спасибо за ответы.

Если уменьшать скорость обработки страницы по версии PageSpeed Insights - то счетчики (особенно Яндекс.Метрика), кнопки поделиться (особенно от Яндекса), видео с YouTube и виджеты комментариев тянут сайт на дно, и это все надо либо кешировать либо убирать. Куда ни глянешь в отчет от Google - все проблемные ресурсы находятся на сторонних сервера.

Сильно ли влияет скорость загрузки на позиции - я так не думаю, скорее это какой-то миф близкий к танцам с бубном.

А вы сами подумайте, откуда клиент узнает что это (пока незнакомый ему ресурс) тот же самый, но на другом сервере? Будет лишний запрос.

Да, так и делают. Но там тоже лимиты есть.

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

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

---------- Добавлено 15.02.2019 в 16:48 ----------

1. Далеко не всегда это лучше чем несколько. Особенно по теме блокирующие / неблокирующие. Часто вообще есть некие объемные ресурсы которые будут долго грузиться, и само по себе это не критично, но они не должны блокировать загрузку других, которые клиент должен загрузить как можно скорее.

2. Далеко не всегда это возможно. Яркий пример со сторонними ресурсами типа сторонних кодов, которые могут и должны часто меняться, при этом полноценное кэширование недопустимо.

ну только полные пофигисты загружают себе на сайт подобное

Это я ступил. Почему-то подумал про загрузку картинки счетчика таким сопобом.

б) Новые пользователи увидят. Старые - нет. Чтобы увидели, нужно после обновления добавить к файлу какой-то новый параметр: .js?v=1234

Например, подойдет дата и время обновления.

Размещал бы я на своем домене, чтобы меньше было "ссылок" на другие сайты. Но это так. Дело вкуса :)

Плюс размещения всего на одном домене - сокращается время получения IP адреса (nslookup) и возможно контент польется через одно единственное подключение, а не каждому файлу отдельно. Это уже тонкости.

А что Вы называете крупным сайтом? Сайт с посещаемостью 30-60 тысяч в сутки считается крупным?

И да, раз тут вопрос о выносе js метрик на поддомен.

Есть ли смысл вынести картинки и подгружать их с поддомена? Фото уже все обработаны, сжаты с guetzli подогнаны по размеру, есть уменьшенные картинки для мобильных экранов, которые подгружаются динамически по мере прокрутки экрана.

Собственно, будет ли смысл выносить их, если трафик, как я писал 30-60 тыс в сутки, а сайт о растениях и в каждой статье от 5 до 15 фото.