Оптимизация отображения большого количества изображений (более 1000) для повышения производительности и удобства использования в веб-приложении.

Question

В нашем веб-приложении пользователям необходимо просмотреть большое количество изображений. Это мой текущий макет. 20 изображений будут отображаться одновременно, с полосой нумерации страниц над миниатюрами. Нажатие на миниатюру покажет увеличенное изображение слева. Увеличенное изображение будет следовать полосе прокрутки, поэтому оно всегда видно. На самом деле довольно просто.

Мне было интересно, каким будет лучший интерфейс в этом сценарии:

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

Другим вариантом может быть что-то вроде Фастфлип от Google .

Как вы думаете, что является лучшим подходом для этого приложения? Радикальные идеи приветствуются.

Answer 1

Я думаю, что вопрос, который вы должны задать, заключается в следующем: какие действия должен выполнять пользователь? Какова цель сайта?

Если «просмотр изображений» влечет за собой оценку каждого изображения, я бы предпочел использовать подход Fastflip, в котором основное внимание уделяется одному изображению. Галерея миниатюр будет отвлекать от желаемого действия и может привести к меньшему количеству фотографий, оцененных / рассмотренных.

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

Просто мой 2с.

Answer 2

• Если вы разбиваете миниатюры на страницы, вы можете предварительно сгенерировать одно изображение, содержащее все миниатюры для каждой страницы, а затем использовать карту изображений для обработки текста при наведении курсора и щелчка.Это уменьшит количество HTTP-запросов и, возможно, приведет к уменьшению количества отправленных байтов.Расстояние между изображениями должно быть минимизировано, чтобы это было наиболее эффективным.Это может иметь некоторые недостатки.

• Чтобы уменьшить размер загружаемого изображения за счет предварительной обработки, вы можете попытаться сохранить каждое изображение в формате (PNG или JPG), наиболее эффективном для его содержимого, используяалгоритм, подобный алгоритму ImageGuide .Аналогичным образом, если изображения плохо сжаты (например, JPEG-файлы с камеры мобильного телефона), их можно повторно сжать за счет некоторого качества.

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

• Выможет воспроизводиться с изображениями JPEG2000 (вы сказали «приветствуются радикальные идеи»), что очень легко, потому что эскиз и основное изображение не нужно отправлять, как если бы они были отдельными файлами.Это преимущество формата сжатия - это не то же самое, что взломать указание браузеру изменить размер полноразмерного изображения для представления его собственного эскиза.

• Вы можете взятьвзгляните на Google WebP формат изображения.

• На стороне сервера отдельный сервер изображений, оптимизированный для доставки статического контента, возможно, с использованием NginX или веб-сервера Tux.

Answer 3

Хотя этот ответ может быть немного не радикальным и скучным, я бы согласился с вашим предложением об асинхронной загрузке миниатюр (и, конечно, основного изображения), если они появляются. Подобная техника используется Google+ на панели для добавления людей в круги. Таким образом вы сохраняете ресурсы сервера и пропускную способность для изображений, которые необходимы клиенту. Как показывает Google+, операции с деревом DOM выполняются достаточно быстро и не замедляют работу компьютеров последних лет.

Вы также можете предварительно скомпилировать несколько строк таблицы миниатюр впереди с фиктивным изображением (например, анимированным GIF "круг загрузки") и заменить изображение. Таким образом, рассматриваемая таблица уже построена и ее не нужно перерисовывать, поскольку элементы потока, следующие за таблицей, должны были бы быть, если во время прокрутки там не было изображений.

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

Answer 4

Я бы показывал эскизы, так как пользователь может захотеть пропустить некоторые картинки.Я бы также избежал нумерации страниц в терминах

<<first <previuos n of x next> last>>

и пошел бы к чему-то более простому в реализации и эффективном.A

load x more pictures.

Никакой бесконечной прокрутки, а почему бы и нет, даже никакой прокрутки вообще.Просто load x more, previous x.