Ajax-запрос к SQL возвращает сотни изображений в JSON -> CSS Sprites?Base64?

Question

Мы пишем веб-календарь событий с тысячами театральных представлений, фестивалей и концертов в базе данных SQL.

Пользователь заходит на веб-сайт, выполняет поиск, сервер SQL возвращает JSON,и код jQuery на стороне клиента отображает 200+ событий.

Наша проблема в том, что у каждого события есть изображение.Если я возвращаю URL-адреса, браузер должен выполнить более 200 запросов HTTP GET для этих крошечных (2–4 КБ) изображений.

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

Я бы предпочел возвращать двоичные изображения как часть JSON и отслеживать, какие изображения мы уже кэшировали, а какие нам действительно нужны.Но я не могу понять, как.Кажется, требуется преобразование в Base64?Есть ли пример кода по этому поводу?

Спасибо за любую помощь, которую вы можете оказать!:)

Answer 1

Похоже, что оригинальный постер продолжил по существу это решение самостоятельно, однако, основываясь на их комментарии о 33% нехватки места, я не думаю, что они наблюдали неожиданное явление, которое вы получаете, когда основываете кучу изображения в один ответный объект , а затем распаковывать его ... хотите верьте, хотите нет, но это может легко привести к общему размеру передачи, который меньше, чем сумма файлов некодированных изображений, даже если каждое незашифрованное изображение было также отдельно упакован.

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

Answer 2

Веб-сайт, который вы используете (StackOverflow), должен предоставить 50 аватаров для 50 вопросов, показанных на странице вопросов. Как это сделать? Браузер делает 50 запросов.

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

Отслеживание загруженных изображений - это не наша работа, а работа браузера. Наша задача - убедиться, что URL-адрес уникален и согласован, а заголовки ответа позволяют кэшировать.

Кроме того, base64 сделает поток как минимум на 33% длиннее, в то время как его обработка на стороне клиента не является тривиальной - я никогда не видел реализацию, но, вероятно, кто-то сделал для нее какой-то javascript.

Я считаю, что все, что вам нужно, это просто нумерация страниц .

Answer 3

Вот что мы решили.

У создания спрайтов есть некоторые недостатки:

• Чтобы уменьшить потерю изображения, нам нужно хранить оригиналы в формате PNG вместо JPEG всервер.Это добавит медлительности, и уже есть некоторая медлительность в создании динамических спрайтов CSS с помощью ImageMagick.

• Чтобы уменьшить размер изображения, конечный спрайт CSS должен быть JPG, ноJPG с потерями и с сеткой изображений, вещи становятся странными по краям, поскольку JPG пытается смешиваться и сжиматься.Мы можем исправить это, поместив пустую рамку вокруг всех изображений, но даже в этом случае это добавляет сложности.

• со спрайтами CSS становится все труднее осуществлять интеллектуальное кэширование;мы должны упаковать все изображения независимо от того, что мы отправили в прошлом.(или мы должны сохранить все старые CSS-спрайты независимо от того, содержат ли они много или мало изображений, которые нам все еще нужны).

• Боюсь, у нас слишком много комбинаций категории даты-расположение для предварительного вычисления CSS-спрайтов, хотя, конечно, мы могли бы обрабатывать часть данных таким образом

Таким образом, наше решение - использовать Base64 для фактической отправки каждого изображения одно за другим.Несмотря на 33% накладных расходов, кодирование и управление гораздо менее сложны, а если учесть проблемы с кэшированием, передача данных может быть даже меньше.

Спасибо всем за совет по этому поводу!

Answer 4

Данные никогда не бывают случайными.Например, вы можете назвать свои спрайты

date_genre_location.jpg

или, тем не менее, организовать свои поиски.Это может стоить того.Может быть.

Вам нужно сделать математику