При оптимизации сайтов на одно изображение из макета приходится сохранять как минимум 9 файлов: 1) оригинал, 2) версии с размерами x2 и x3 для retina-дисплеев, 3) версии в форматах webp и avif для всех вышеперечисленных изображений. Например, из одного маленького hero.jpg получается: <i>(9 файлов на одно изображение, и это ещё без учёта mozjpeg и адаптивных изображений для различных устройств).</i> В связи с этим, возникает логичный вопрос: как эффективно организовать хранение всех этих файлов? Разве нецелесообразно хранить их просто в одной папке ./images? При наличии всего 10 изображений в макете (что достаточно для небольшого лендинга) получается минимум 90 файлов.
Для эффективного хранения оптимизированных изображений в вашем проекте можно использовать несколько подходов. Главное — организовать структуру каталогов так, чтобы она оставалась понятной и удобной для работы, особенно когда количество изображений растет. Вот несколько советов:
### 1. Структура каталогов
Разделите изображения по типу и размеру, используя иерархическую систему папок. Например:
```
/images
/hero
original.jpg
[email protected]
[email protected]
hero.webp
hero.avif
/products
/product1
original.jpg
[email protected]
[email protected]
product1.webp
product1.avif
/product2
original.jpg
[email protected]
[email protected]
product2.webp
product2.avif
...
```
### 2. Нэйминг файлов
Используйте чёткие и информативные имена файлов, которые будут включать тип изображения и его назначение. К примеру, `[email protected]` будет легко идентифицировать как версию `hero` для дисплеев retina.
### 3. Автоматизация процесса
Используйте инструменты для автоматизации работы с изображениями, такие как Gulp или Grunt. Вы можете настроить их для автоматического создания всех необходимых версий изображений и их сохранения в нужные папки. Например, вы можете использовать такие плагины, как `gulp-image`, `gulp-webp` и `gulp-avif`.
### 4. Документация и гайды
Создайте README-файл или документацию в папке с изображениями, где вы опишете структуру, назначение каждой папки и пример названий файлов. Это поможет вам и другим членам команды быстрее ориентироваться в проекте.
### 5. Хранение в системе контроля версий
Если у вас есть много изображений и они часто обновляются, рассмотрите использование системы контроля версий, например Git. Но будьте осторожны с большими файлами; для хранения больших медиафайлов можно использовать Git LFS (Large File Storage).
### 6. Использование CDN (Content Delivery Network)
Если ваш проект предполагает большое количество трафика, вы можете использовать CDN для хранения и быстрого доступа к изображениям. Такой подход также поможет оптимизировать загрузку изображений.
### 7. Адаптивные изображения
Для реализации адаптивных изображений, посмотрите на использование таких атрибутов, как `srcset` и `sizes` в HTML. Это поможет вам избежать хранения большого количества версий одного изображения.
Следуя этим рекомендациям, вы сможете структурировать вашу проектную папку с изображениями так, чтобы она была организованной, понятной и легкой для использования.
1. То, что вы спрашивали. Если вы каждое изображение генерируете вручную, и потом вручную кладете в эту директорию, то тогда да, желательно для удобства разбивать. Можно, например, для каждого изображения создать директорию, имя которой будет совпадать с именем файла, а внутри неё будут храниться отдельные файлы. В вашем случае директория будет называться hero , а файлы: image.jpg, image-retina.jpg, image-20x20.jpg, image-200x200.jpg и т.д. Ссылки на все изображения будет легко писать, потому что менять надо будет только название директории.
2. Генерация при сборке. Если у вас есть одно оригинальное изображение, из которого при сборке автоматически, скриптом, делаются все остальные размеры, то вам лучше всего в проекте создать директорию assets , в которой будут храниться оригиналы. И настроить сборку так, чтобы все эти сгенерированные изображения (и оригинал, если нужно) бросались в директорию static/images , которая и будет настроена на вебсервере, как директория со статическими файлами.
При автоматической генерации вам абсолютно до лампочки, будут ли они все в одной директории, или же в разных. И ссылки будет делать несложно.
3. Динамическая генерация. Если вы пишете что-то типа CMS, то изображения вам могут заливать через сам сайт, и надо будет как-то генерировать для них различные форматы. Тут у нас будет комбинация с п.2.
Все те изображения, которые вы делали при разработке сайта, будут генерироваться при сборке.
А если пользователь добавит своё изображение, то оригинал мы сохраним в какую-то директорию files/user/images на бэкенде. Она будет недоступна из браузера.
Бэкенд сможет генерировать такие же разноформатные файлы из этого оригинального изображения, и складывать их в директорию static/images/cache , которую мы тоже откроем для вебсервера.
Вебсервер настроим так, чтобы при передаче ему ссылки https://my-site.com/ static/images/cache/hero-retina.jpg он сначала искал её прямо по этому пути, а если не найдет, то перенаправлял бы запрос на какой-то внутренний ресурс, который бы генерировал это изображение на лету, складывал бы его в директорию static/images/cache , и одновременно отдавал бы это изображение вебсерверу. А уже в следующий раз, когда браузер запросит это изображение, вебсервер снова сначала будет искать его в файлах в static/images/cache , и уже найдёт его там, он закешируется ещё и браузером, и будет молниеносно отдаваться. Таким образом у нас получится отложенная генерация изображений только тогда, когда они действительно нужны, когда браузер их напрямую запрашивает.