1. Потому что может быть ситуация, когда большая картинка вжата в маленькое окно для того, что бы потом отобразить её в большом окне (кейсов много, к примеру лупа на главном и единственном фото товара). Нет смысла грузить два изображения, когда можно загрузить одно и крайне высоки шансы его просмотра. Гугл не может отследить такие кейсы, поскольку они через JS триггер.

2. Не гугл аналитику, а вообще скрипты. https://developers.google.com/speed/pagespeed/insights/?hl=RU&url=toolbox.googleapps.com%2F Некоторые ресурсы блокируют первую отрисовку страницы. Рекомендуем встроить критическую часть данных JS/CSS в код HTML и отложить загрузку остальных ресурсов. https://web.dev/render-blocking-resources/?utm_source=lighthouse&utm_medium=unknown

3. Тут не о CDN речь, а о ответе сервера. Вот. При этом ты вполне можешь отдавать свой сайт за 10 мс русскоязычным пользователям, но пейдж спид будет уменьшать оценку из-за того, что к серверам гугла страница отдаётся за 600 мс сквозь трансатлантические кабеля. А  CDN вообще отдельная тема и я не считаю, что CDN помогают хотя бы в большинстве случаев мелко-средних сайтов.

4. Речь о js/css/fonts, да, но только владелец может знать какое время выставлять и нужно ли выставлять (сайты бывают разные, в том числе и тестовые).

5. Согласен

6. Если приложение сконструировано так, что ему срать на загрузку (нужных) скриптов во время работы сайта, то нечего указывать нужно ли эти скрипты как-то оптимизировать (они уже не влияют на интерактивность сайта).

7. Это ты через html-теги это можешь всё красивенько сделать. А ты попробуешь через стили без JS кода нормально организовать подобное. Я бы посмотрел (даже в 2020ом). В итоге ебаное дерьмо. Особенно совет юзать JPG2000, когда в этом формате изображения наоборот растут, а safari webp не поддерживает.

Может тайну открою, но пакеты могут ходить не напрямую в нужное тебе место. В итоге 500мс задержка вполне реальна

Может тайну открою, но пакеты могут ходить не напрямую в нужное тебе место. В итоге 500мс задержка вполне реальна

300 в среднем) но и да, 500 тоже вполне реальна

1. Потому что может быть ситуация, когда большая картинка вжата в маленькое окно для того, что бы потом отобразить её в большом окне (кейсов много, к примеру лупа на главном и единственном фото товара). Нет смысла грузить два изображения, когда можно загрузить одно и крайне высоки шансы его просмотра. Гугл не может отследить такие кейсы, поскольку они через JS триггер.

2. Не гугл аналитику, а вообще скрипты. https://developers.google.com/speed/pagespeed/insights/?hl=RU&url=toolbox.googleapps.com%2F Некоторые ресурсы блокируют первую отрисовку страницы. Рекомендуем встроить критическую часть данных JS/CSS в код HTML и отложить загрузку остальных ресурсов. https://web.dev/render-blocking-resources/?utm_source=lighthouse&utm_medium=unknown

3. Тут не о CDN речь, а о ответе сервера. Вот. При этом ты вполне можешь отдавать свой сайт за 10 мс русскоязычным пользователям, но пейдж спид будет уменьшать оценку из-за того, что к серверам гугла страница отдаётся за 600 мс сквозь трансатлантические кабеля. А  CDN вообще отдельная тема и я не считаю, что CDN помогают хотя бы в большинстве случаев мелко-средних сайтов.

4. Речь о js/css/fonts, да, но только владелец может знать какое время выставлять и нужно ли выставлять (сайты бывают разные, в том числе и тестовые).

5. Согласен

6. Если приложение сконструировано так, что ему срать на загрузку (нужных) скриптов во время работы сайта, то нечего указывать нужно ли эти скрипты как-то оптимизировать (они уже не влияют на интерактивность сайта).

7. Это ты через html-теги это можешь всё красивенько сделать. А ты попробуешь через стили без JS кода нормально организовать подобное. Я бы посмотрел (даже в 2020ом). В итоге ебаное дерьмо. Особенно совет юзать JPG2000, когда в этом формате изображения наоборот растут, а safari webp не поддерживает.

1. Воу. кто ж так делает то? А если я не хочу "лупу"? посмотри как в амазоне сделано например

2. Это правильно. Когда-то смотрел как браузер "кушает" скрипты?

3. Из рашки в америку 200-300мс, откуда 600?

4. js/css/fonts должны иметь max ttl, при чем тут владелец?

6. Даже хз что сказать) если срать на производительность и юзеров, зачем замерять тогда?

7. source sets есть такая штука в html

короче хз о чем еще говорить. тут все описано что и зачем делается https://web.dev/fast/

1. Я тебе для примера привёл. Кейсы вполне есть.

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

3. Уже ответил

4. При том, что владелец сайта сам выбирает ttl ресурсов, днс записей и прочего в зависимости от контента сайта и никто ему указывать не должен. Хоть ttl 1, если на это есть причины.

6. С чего ты взял, что срать на производительность юзеров? Пока человек делает одно в фоне подгружается другое, что бы потом не ожидать 100500 секунд на прогрев. Это довольно популярная практика (как вк погружает 5 следующих фото в фоне когда ты листаешь их, к примеру)

7. Это html теги, о чём я тебе и писал.

Как я говорил выше, в зависимости от кейсов page speed может быть необъективным и полагаться на его оценку в каждом из случаев — булшит. Нужно плясать от задач конкретных страниц/приложений.

1. Особенно клево когда 4к картинки грузят и таких десяток на странице. Юзера на телефонах аж пищать будут

когда на него можно забить - это какая-то совсем закрытая разработка и тебе похер на юзер перформанс. остальное все это твое имхо

покажи мне вообще конкретный сайт, иначе это разговор ни о чем

Можешь на него взглянуть, если уж так хочеться. Как видишь, там идут ссылки на CDNки с весьма популярными скриптами, которые наверняка уже закешированы у пользователя. При этом сам гугл для своего же ресурса предлагает встроить их в тело, тем самым пользователю нужно будет каждый раз загружать всё большее тело страницы.