Как стать автором
Обновить

Комментарии 41

Из этой статьи я узнал, что Facebook использует разные иконки глобусов для пользователей из разных стран.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Если вы вынесете статику с сыром виде (без объединения мелких файлов в один большой), то это будет практически так же плохо, как и отдача их со своего сервера. А если соберете в кучу, то cdn даст эффект только если на сайт ходят пользователи с разных уголков планеты (но тут надо будет решить, как быть с html).
Да и в случае нормальной оптимизации и канала на сервере, этот эффект будет не очень весомым т.к. ускорит работу пользователей провайдеров у который есть сильный приоритет локального трафика (допустим, канал у провайдера гигабит на мир и по гигабиту в каждую локальную точку обмена). Если у пользователя хороший интернет, то малое количество больших файлов он скачает не хуже, чем пользователь где-то рядом.
Почему статика в сыром виде будет так же плоха?
Все картинки могут быть принудительно заранее закэшированы на всех серверах CDN. CDN также может раздавать по HTTP2
Потому, что статика с CDN будет раздаваться так же медленно, как и с сервера сайта. Разница будет только если пользователь на другом конце света. Но даже в этом случае, множество запросов и ответов увеличат время загрузи и возможно это будет медленнее, чем отдать весь спрайт с далекого но быстрого сервера.
10 запросов будут скорее медленнее даже на мобильном интернете. Часто скорость отдачи данных сильно меньше скорости приема и для мобильного интернета это выльется в то, что ожидание каждой картинки будет довольно длительным.

Плюс спрайта в том, что при переходе на другую страницу, спрайт (а так же стили и js) будут уже взяты их кэша и запросов за ними вообще не будет. А если страница такого сценария не предполагает (допустим, строго одностраничный сайт), то лучше собрать просто правильный спрайт без лишних данных, чем отдавать 10 отдельных картинок.
НЛО прилетело и опубликовало эту надпись здесь
а если их грузить отдельно то как только иконка загрузится она уже будет отображена даже если все остальные еще не загрузились, в результате отображение хоть чего-то на странице вы увидите раньше чем если бы это был один тяжёлый спрайт.
К сожалению, на многих сайтах это «отображение хоть чего-то» будет еще несколько секунд дергаться, перерисовываясь после загрузки очередной иконки.
НЛО прилетело и опубликовало эту надпись здесь
Пустого экрана от спрайтов не будет, это ж не css. Да и разница между тем, что отображается на конкретной странице и общим содержимым спрайта редко бывает большой.
НЛО прилетело и опубликовало эту надпись здесь

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


Для того, чтоб ничего не прыгало, следует указывать размеры блока, в котором находится картинка. Что, впрочем, не всегда возможно. Тем не менее, что удобнее — появляющиеся в рандомном порядке 10 (например) иконок или появление их одновременно всего через секунду, а то и пол — вопрос.

В случае спрайтов, размеры элемента можно указать всегда. Они ведь известны т.к. нужны для правильного позиционирования в самом спрайте.
Если спрайт разумного размера, то загрузится он не сильно дольше, чем отдельные иконки. Потому, что для каждой иконки отдельный исходящий запрос (а это боль на мобильном интернете), отдельные заголовки как при получении, так и при запросе и потом браузер для каждой картинки будет создавать объект и т.д. В итоге, страница будет хреново работать, пока эти картинки прогружаются, если у пользователя слабое устройство.
В отзывчивости зачастую выигрывает — при большом пинге на могильном интернете каждая картинка подгружается с заметной паузой — заметил, когда с такого пришлось зайти на сайт с кучей мелких картинок (инет 4G — видео можно смотреть и ютуб по дефолту FHD подсовывает, но вот соединения — ужасны).
НЛО прилетело и опубликовало эту надпись здесь
соответственно картинка в 14 килобайт уйдёт 1 пакетом, а картинка в 15 килобайт двумя пакетами
Скорее будет 10 и 11 пакетов соответственно.

Но да, согласен, round trip-ы надо экономить.

Может с server push разница не будет так заметна, а в реальных сценариях использования будет выигрыш за счет пропуска неиспользуемых спрайтов (зачем мне 4 набора спрайтов глобуса, если 3 из них я никогда не увижу?) и более оптимальной работы кэша (при редактировании одного спрайта необходимо перезагрузить лишь измененный спрайт вместо всего суперспрайта)?

Потому, что объем картинки такого глобуса, который вы никогда не увидите, сравним с объемом заголовков в запросе. Только запрос еще и надо обрабатывать, тогда как дополнительный глобус никаких действий не требует и оверхед от него минимальный, если вообще есть с учетом заголовков.

Но ведь в статье именно это и тестируется — худший случай, когда используется только 10% изображений из спарйта.

Использование http/2 ведет к использованию шифрования.
Если отдавать много жирной статики, то будет дополнительная нагрузка на проц для ее шифрования.
А также задержку дает начальная установка соединения.

Для себя пока остаюсь на http, никаких секретных данных не передается, ну кроме паролей.

А также сертификат стоит денег.

А также не все сервера его поддерживают (шаред-хостинги).
НЛО прилетело и опубликовало эту надпись здесь
Для бесплатных сертификатов уже даже выбор есть, я знаю три центра выдачи бесплатных сертификатов.

С тем, что столкнулся, это какая-то муть. Для какого-то сертификата нужно на сервере установить демон, который будет ходить и обновлять сертификат, так как он выдается на 3 мес. Дополнительная дыра в безопасности. Да и на шареде не будет работать. (перечитал ваш коммент до конца, да это, вроде и был Let's Encrypt)

Но да, есть бесплатные cloudflare при использовании его cdn, работает автоматом и ничего настраивать не нужно.
Благодаря SNI

Я имел в виду не поддерживают http/2, но и касательно SNI — он тоже не везде.

Хотя, кому нужен https, они на него перейдут, но вряд ли из-за http/2. http/2 — это бонус.
НЛО прилетело и опубликовало эту надпись здесь
В HTTP/1.x не более одного запроса (прим. одновременно) возможно в пределах одного TCP соединения между клиентом и сервером.

Это не так. Запросы в HTTP/1.1 можно пайплайнить. К сожалению, браузеры этим не пользуются из-за возможности наткнуться на том конце на сервер, который плохо работает с пайплайнами (из популярных и современных таких нет, но все же).

Исследование в статье неверное, так как строится не неправильном понимании HTTP/2. Просто смена протокола даёт не самое большое ускорение и не позволяет заменить спрайты. Но протокол даёт новые инструменты, с помощью которых как раз можно и добиться существенного ускорения.

Для замены спрайтов есть специальный инструмент pre-push. Это когда сервер может ответить сразу несколькими файлами на один запрос. Например, пользователь запрашивает index.html, а сервер сразу отвечает index.html, app.css, logo.png, img1.png, img2.svg.

Очевидно, что pre-push как раз позволяет сделать такой аналог спрайта (все файлы уходят на один запрос). pre-push даже гораздо лучше спрайтов, так как в одном ответе может быть и HTML, и PNG, и SVG.

Кроме того, pre-push может быть гораздо умнее спрайтов и отвечать только новыми картинками, если только часть из них обновилась.

Соответственно, нужно тестировать не просто HTTP/2, а новый веб-сервер, который поддерживает pre-push. К сожалению, такого сервера (или сборщика) ещё нет. Поэтому все разговоры про то, что HTTP/2 уже здесь — преждевременные.
НЛО прилетело и опубликовало эту надпись здесь
Как конкретно делать pre-push — второй вопрос. Можно заранее составить картинку зависимостей. И использовать какой-то аналог E-Tag на клиенте (старый E-Tag не подойдёт)
Например, пользователь запрашивает index.html, а сервер сразу отвечает index.html, app.css, logo.png, img1.png, img2.svg.

А ты давно делал приложение, в котором index.html, app.css и logo.png были на одном сервре или одном домене?


И использовать какой-то аналог E-Tag на клиенте (старый E-Tag не подойдёт)

Поправь, если неправ, но вроде браузеры не посылают никакой новый e-tag, который нам позволил бы узнать, что у браузера уже есть в кеше. А значит протокол не даёт новые инструменты, с помощью которых можно добиться существенного ускорения.

Разносить на разные сервера нужно было в HTTP/1 из-за ограничения кол-ва запросов. В HTTP/2 весь смысл этого пропадает.

Не из-за ограничения кол-ва запросов, а потому что сервер со статикой легко и просто расположить у пользователя под боком (CDN), а сервер с приложением нет.

Да, хороший вопрос, как делать CDN на базе HTTP/2. Можно сделать в виде прокси-сервера. Клиент подключается в CDN и запрашивает index.html. CDN проксирует запрос на index.html в главные сервера, а сам в это время начинает отдавать статику (по заранее подготовленной сборщиком таблице зависимостей)
«Замену E-Tag» можно сделать через обычный cookie.

Но получается, нужно будет в куку пихать ключ: значение, где ключи — путь к статике, а значение — ревизия. Это очень много для куки — в примере из статьи в спрайте 72 картинки. Если сделать одну общую ревизию на всю статику, мы возвращаемся к тому, что при изменении одного файла будет скачиваться вся статика (на этот раз она будет пушится).

Можно проще — положить куку last_request со временем последнего запроса. Если статика изменилась с последнего запроса — шлём новую версию.
НЛО прилетело и опубликовало эту надпись здесь
Не понял. Можете подробнее описать?
НЛО прилетело и опубликовало эту надпись здесь
Всё равно его не брошу, потому что он хороший?
Кто в здравом уме будет внедрять в свои проекты такие новейшие технологии, как HTTP/2, и при этом тащить этот антиквариат в виде png-спрайта из одноцветных простейших иконок, да ещё и большая часть которых — шестикратное повторение одного и того же но с другим цветом? Может всё-таки сначала надо свой фронтенд подтянуть и заменить таки png на svg (для иконок как минимум), а потом уже тюнинговать сервак и думать, спрайт или не спрайт?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории