Краща практика - обробка зображень на веб-сайті


9

Я переношу старий сайт електронної комерції на MVC 3 і хочу скористатися вдосконаленнями дизайну. На даний момент на сайті є зображення товарів, що зберігаються у 3-х розмірах: ескіз, середній (для відображення в списку) та розширений для збільшення масштабу. Зараз нам доводиться завантажувати 3 окремі зображення, розміри яких відповідають правильному розміру, надавати 3 різні назви, які відповідають тому, що сайт очікує, і т. Д., Це біль.

Я хотів би завантажити лише 1 великий файл, а потім дозволити сайту зменшити його до потрібних розмірів, і я хотів би можливість змінити мініатюру та розмір списку залежно від переваг користувача, фактор форми (наприклад, мобільний, iPad , робочий стіл) тощо, тому може знадобитися багато копій одного зображення. Моє запитання: чи слід зменшувати зображення, а потім зберігати його кілька разів після завантаження, і якщо так, що таке хороша умова зберігання / іменування?

Інша ідея - зберегти лише одне зображення, але змінити його розмір програмно перед тим, як подавати його клієнту. Хтось робив це, і які ще були компроміси, крім кількох машинних циклів? Як ви передаєте клієнту тимчасове зображення в пам'ять (немає URL-адреси)?

Відповіді:


13

Я є провідним розробником туристичної компанії, що працює у Великобританії. Одним із проектів, які я реалізував, була веб-версія нашої бібліотеки зображень, яку можна автоматично запитувати, щоб надати фотографію для нашого сайту. Він містить близько 150 000 зображень, з яких близько 60-70k доступні на веб-сайті (найвищий рейтинг).

Ми почали, визначивши приблизно 5 розмірів, створивши ці версії розмірів на льоту і зберігаючи їх в Amazon S3. Ціна була мінімальною, але Amazon побудований для виходу з ладу витончено, тому ми часто бачили відсутні зображення. Чим більше ми розробляли наш веб-сайт, тим більше ми ненавидів лише доступні п'ять розмірів зображень.

Ми перейшли до моделі динамічного розміру, завдяки чому ми можемо додати параметри ширини та / або висоти до URI будь-якого зображення, щоб воно відображало цей розмір на льоту. Ми кешуємо змінене зображення (використовуючи хеш MD5 запиту URI запиту як імені файлу).

Щоб отримати зображення № 12345 (наші зображення витягуються через db, але ви можете замінити це на шлях до файлу) шириною 200 та якістю jpg 80%, формат URI буде таким:

http://images.domain.com/?imageid=12345&w=200&q=80

Це рішення було легко здійснити і працює безперебійно - немає помітної затримки відвідувача веб-сайту, навіть на сторінках з 20-30 зображеннями.

Ми все це робимо з .net, хоча я також написав сценарій зміни розміру PHP, який робить те саме.

Сподіваюся, що допоможе, Адам


Для мене найсмішніше, що "передбачувальна зміна" - це, власне, форма кешування - просто надзвичайно примітивна і обмежена. Кешування після першого запиту - це звичайний підхід, і - як правило - кращий. Виняток - коли ви інакше матимете справу з величезними обсягами даних відразу , що, мабуть, не так.
Aaronaught

Блискучий @Adam (це найкращий мій виступ у Великобританії), дякую за продуманий пост. Я йду.
Стів

2

ImageProcessor ImageProcessor

Imageprocessor - це легка розширювана бібліотека, написана на C #, що дозволяє вам керувати зображеннями на ходу за допомогою .NET

Змінення розміру на льоту:

<!--Automatic height based on width-->
http://your-image?width=600
<!--Automatic width based on height-->
http://your-image?height=250
<!--Both dimensions specified-->
http://your-image?width=600&height=250
<!--Both dimensions specified with the image anchored to the top-->
http://your-image?width=600&height=250&anchor=top
<!--Height ratio passed for automatic scaling-->
http://your-image?width=600&heightratio=0.416
<!--Width ratio passed for automatic scaling-->
http://your-image?widthratio=2.4&height=250
<!--Background color added to padded image-->
http://your-image?width=600&height=250&bgcolor=fff  

ImageProcessor.Web стандартно поставляється з кешуванням . Будь-яке оброблене зображення асинхронно кешується як у веб-переглядачі, так і на сервері протягом вибраної вами довжини. Кеш-сервер інтелектуально зберігає мільйони зображень і мовчки оновлює себе у разі зміни оригінального зображення або закінчення терміну дії кешу.


1

Якщо припустити, що мініатюра - це просто змінена версія основного зображення, то, я думаю, це слід зробити під час завантаження, але, можливо, заплановано як фонове завдання, щоб не впливати на інші процеси. Якщо ви змінюєте розмір під час руху, переконайтесь, що ви кешуєте зображення.

У цьому втілення полягає в тому, що найкраща мініатюра для деяких зображень - це не простий розмір майстра; вам може знадобитися масштабування та обрізання способом, керованим людиною. Можливо, ви захочете зробити функцію автоматичного зміни розміру, але мати механізм, який дозволяє переосмислити в цих конкретних випадках.


0

Незначна зміна того, що згадував Адам:

(1) створити користувацьку сторінку помилок (правило для зображень)

(2) Структура імен файлів зображення повинна бути такою:

ImageId_Width_Height_Quality

Єдиним винятком є ​​оригінальне зображення, яке має бути названо:

ImageId_Original

(3) При завантаженні файлу, наприклад: 1245_Original -> всі файли з 1245_ * слід видалити

(4) Спеціальна сторінка помилок (припускаючи, що існує 1245_Original Existing) повинна динамічно створювати запитуваний файл зображення, наприклад:

1245_250_400_80.jpg

а також подавати її в перший раз.

Фактично завантаження нового зображення очищає кеш-пам'ять.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.