Comments 7
1) клиенту может это все и не нужно (мобильный интернет)
2) у клиента уже есть эти данные закешированные, все что ему хочется знать это 304 NOT MODIFIED
не могу понять почему многие текущие разработки идут по принципу:
1) у пользователя простаивает cpu, надо его загрузить хоть чем-то
2) у пользователя простаивает канал в интернет, давайте мы по push закешируем весь сайт и пару поддоменов в нагрузку, может понадобится
Мне кажется эти моменты в конце статьи озвучены.
другая ситуация что 51% это возможно и надо, поэтому оставшиеся 49% тоже будут страдать, так как врубается на всех сразу
уверен многие последний абзац даже не будут читать, так как по всей статье идет внушение что server push это отличнейшая технология которую просто обязан внедрить каждый, кто хочет уменьшить скорость загрузки страницы
Ну, как по мне, статья практически по учебнику написана — введение, объяснение зачем это надо, пример использования в Go с кодом и объяснением, разбор когда это нужно, а когда нет, предостережения и ссылки в конце.
Если вам кажется, что статья написана с позиции "есть возможность — надо использовать", можете посоветовать, как лучше написать её, чтобы не было такой позиции? Я могу передать фидбек автору. Спасибо.
Эти моменты озвучены, но никакого решения не предусматривается. Я не знаю, как Google оценивает эффективность от внедрения подобных методов, но бьюсь об заклад, что если эта штука взлетит, то 95% сайтов будут тупо пушить все. Потому что умные и сложные решения не приживаются, 95% сайтов делается по принципу «тяп-ляп и в продакшн».
У меня это больное место, потому что я сейчас в Непале, где дорогой, ненадежный и медленный интернет. И я вижу, как даже мобильные версии сайтов, «мобильные» только в том смысле, что адаптированы под небольшой экран (да и то с оговорками). С точки зрения же потребления трафика, они грузят просто десятки мегабайт ненужного мусора.
HTTP/2 Server Push в Go 1.8