Отдача мелкой графики

[@StopDesign]

Почему аватарки нельзя кешировать?
Есть данные по скорости отрисовки страницы при таком подходе? Например, на сотне картинок.

[@gregory_777]

При 20-30 картнках общим объёмом 50-60кБ — субъективно быстрее. Объективно измерить сложно, т.к. загрузка картинок начинается после окочания рендеринга страницы браузером.

[@hotach]

А почему бы на сервере не собирать из аватарок спрайт?

[@gregory_777]

А если пользователей 100500?

[@jil]

Ну тут можно ход конем: форумы обычно постраничные, т.е. на странице 10-50 постов, в большинстве случаев с меньшим количество уникальных аватар. А значит, теоретически, можно создавать спрайты для популярных страниц, или даже веток обсуждения.
Ну или создавать спрайты самых активных/популярных юзеров/аватар…

[@docomo]

> Таким образом мы на порядок снижаем количество запросов к серверу, а значит повышаем стойкость сайта к DDoS-атакам

Я пропустил тот день, когда боты стали массово грузить еще и графику?

Идея интересная, но вся статья полна какой-то чуши, которую вы как-то уверенно так подаете. Например, с какого это перепугу блочная верстка вдруг заставляет браузер интенсивнее «бомбить» сервер запросами на отдачу мелкой фигни? Что за особенности стриминга текстовых данных? gzip что ли?

Как итог, вы перевесили всю тяжесть с клиента на сервер. К вам пришло разом, скажем, 100 человек. 100 одновременных PHP-процессов (дай бог, чтобы вы при этом не уперлись в лимит) из базы (нахрена здесь база?) собирают base64 в один огромный JSON-массив. Клиенты по-прежнему ждут, но уже не потому, что дохрена «мелкой фигни», а потому что дохрена тяжелых коннектов у сайта.

Если хотите немного ускорить отдачу статики, используйте, например, шардинг файлов на несколько доменов: www.stevesouders.com/blog/2009/05/12/sharding-dominant-domains/

[@gregory_777]

К вам пришло разом, скажем, 100 человек. 100 одновременных PHP-процессов (дай бог, чтобы вы при этом не уперлись в лимит) из базы (нахрена здесь база?) собирают base64 в один огромный JSON-массив.

Ну с этим-то проблем как раз нет — можно кешировать выдачу сервлета в memcached и отдавать всё это через nginx например.

[@docomo]

Да, но в таком случае количество возможных ключей будет равняться x^n, где x — кол-во различных ID картинок, а n — кол-во мест их размещения на странице (если речь про один лейаут). Иными словами, это все возможные вариации одновременного появления n картинок из числа x. Даже для 100 картинок на 10 мест это уже нереальное количество. Другого варианта стандартный модуль memcached в nginx вам не предоставит.
Если же вы хотите прямо в nginx разбирать запрос на отдельные ID, лезти в кэш и склеивать все полученные данные (плюс, получать отсутствующие другим путем) и отдавать json, то я с удовольствием посмотрю на этот конфиг :) Perl, Lua?

[@gregory_777]

Что-то я под утро плохо соображаю. Почему 100 картинок на 10 мест?

У нас есть лента новостей. Скажем из 20 блоков. Каждый блок это картика + текст со ссылкой. Страница запрашивает 20 картинок соответственно. Все 20 картинок собираются в одну JSON-стороку, которая и кешируется. Следующая страница — ещё 20 картинок ещё одним куском.

При изменении (при добавлении новости) страницы JSON в кеше пересобирается бэкендом принудительно.

[@docomo]

Для этого случая можно и спрайт собирать :)
Я имел в виду вариант динамического вывода, когда, скажем, каждому пользователю отображается своя лента, плюс блоки с рандомным контентом и т.д. То есть более живую версию сайта.

[@gregory_777]

Вот честно говоря не знаю, проще ли это. Насколько я понимаю, манипуляции с картинками (склеивание) более затратны, чем сериализация…

Спрайты хороши для всяких графических буллитов, стрелочек, штучек и пимпочек, хотя я в последнее время предпочитаю опять же использоваться data:image url.

[@PavlovM]

1) Почему «крафики»?

2)

Особенно учитывая особенности блочной вёрстки, которая в отличие от табличной заставляет браузер интенсивнее «бомбить» сервер запросами на отдачу мелкой фигни

Что вы имеете ввиду..?

[@gregory_777]

1) Ой!

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

[@falstaf]

В итоге имеем невалидную вёрстку и идущих лесом посетителей с отключенным JS.
Да и само решение, если честно, весьма сомнительно.

[@Anonym]

...WHERE ROWID IN (".trim($_GET['q']).") LIMIT 20...
Вы бы так не делали.

[@gregory_777]

Это просто пример, я отлично понимаю, что так делать нельзя.

[@Anonym]

Вы подаете плохой пример. Не все понимают, что так делать нельзя.

[@namikiri]

По-моему, современные браузеры и серверы поддерживают атрибут Connection: keep-alive для подобной «мелюзги».
В итоге браузер создаёт всего один коннект и делает сразу десятки запросов к серверу.

[@homm]

Надо заметить, что далеко не сразу. Общение происходит в режиме запрос-ответ-запрос-ответ. А тут один запрос и один ответ.

[@weirdan]

Ну так на это есть http pipelining, который позволяет сделать сразу несколько запросов.

[@justboris]

А что делать пользователям с медленным интернетом и отключенными изображениями? При таком подходе они их получат принудительно и не будут этому рады

[@Jedi_Knight]

Connection: keep-alive

решает проблему только частично — пока текущая картинка не пришла, следующую запросить нельзя. По-хорошему надо использовать атласы: www.altdevblogaday.com/2012/09/17/building-an-html5-game-dont-shrug-off-atlases/
Вот как это прописать в css: css-tricks.com/css-sprites/

[@gregory_777]

Нет, в данном случае мы получаем сразу все картинки одним куском.

[@Jedi_Knight]

Вместе с созданием кеша страницы можно создать и атлас. По сравнению с приведённым решением есть один плюс — данных придётся передать меньше, и минус — упаковка требует времени.

[@FuriCuri]

Если я правильно понял, то при вашем подходе поисковики не увидят кучу картинок на вашей странице что отрицательно скажется на трафике из поиска картинок (естественно, alt-ы у вас должны быть прописаны корректно).

[@vasilisc]

Топ-10 советов о том, как увеличить скорость загрузки страницы
habrahabr.ru/post/137239/

1. Уменьшите количество HTTP-запросов…

[@gregory_777]

Ну так я для этого всё и затеял. Это в общем-то те же спрайты, только без предобработки графики.

[@Koshelew]

У меня вопрос, а почему нельзя эти картинки сразу отдавать в base64 в теле страницы? Если уж мы всеравно рассматриваем вариант хранить их в базе?

[@gregory_777]

Предпоагается их отдавать с другого домена.

[@kirilloid]

Я просто оставлю это здесь: ru.wikipedia.org/wiki/SPDY

[@PatapSmile]

Гугл в поиске по изображениям иногда отдает картинки через data:image.

Может кто сталкивался: зачем и как такое реализовать?

[@ToSHiC]

Вроде ж современные браузеры не делают больше 6-8 коннектов на домен. Если keep-alive включить, то очень неплохо и так будет отдаваться, по 6 штук параллельно. К тому же у меня есть подозрение, что браузеры не в случайном порядке картинки подгружают, а сначала те, что помещаются на экран, а потом уже те, что есть на странице, но в данный момент пользователю не видны.

[@Wott]

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

[@dmgorsky]

А как насчёт

<img width="..." alt="..." src=«data:image/gif;base64,......» />

?