Где хранить фото для сайта 2023
Продолжая тему оптимизации картинок, я решил исследовать вопрос: где хранить фото для сайта?
Смысл в том, что я решил хранить (скорее всего) все картинки сайта не на хостинге, а на сторонних ресурсах. Выгод тут много:
- Можно разгрузить хостинг, уменьшив занимаемое дисковое пространство.
- Можно разгрузить ресурсы сервера, так как закачка картинок будет происходить со стороны.
- При переносе сайта на другой хостинг нужно будет перенести только базу данных.
Но понятно, что тут есть и возможные минусы:
- Картинки ваши могут удалить, поэтому хранилище должно быть надёжным.
- Скорость загрузки картинок должна быть на высоте.
И вот я решил провести исследование, куда бы закачать и откуда будет быстрее качаться. Использовать я буду известные социальные сети, на которые можно загрузить фото и взять прямую ссылку. Итак, какие есть кандидаты?
Кстати, спрошу как искусственный интеллект про это, что он мне ответит? Он ответил вот что:
Где можно хранить фото для своего сайта?
Для хранения фотографий для сайта можно использовать различные способы.
Также можно хранить фотографии на самом сервере, на котором размещен сайт. Для этого нужно будет создать отдельную папку для хранения изображений и указать путь к ней в HTML-коде страницы. Однако такой способ может быть менее удобен, так как требует наличия сервера и большего объема дискового пространства.
В некоторых случаях может быть удобно использовать встроенные средства хранения изображений, предоставляемые платформами для создания сайтов, такими как WordPress или Joomla.
Хорошая попытка, но я сделаю и свой эксперимент…
1. Сам хостинг (проверим его скорость, вдруг она будет в разы больше?)
2. Twitter
3. Pinterest
4. Яндекс фото
5. Вконтакте
6. Tumblr
7. Blogger
Ну все, пока хватит, семь — хорошее число. Я возьму вот эту картинку, 700х466 и весом 511 Кб.
Вопрос теперь в том, как тестировать? Необходимо использовать сервисы для проверки скорости сайта, но только российские, так как основной контингент на моих сайтах — люди из России. Поищем….
Вот, нашёл один неплохой российский сервис, показывает всё чётко, не много, но по делу, находится тут — Sitespeed
Ну что, начнём тест, по списку….
1. Сам хостинг: Общее время загрузки 3.19 секунд
2. Twitter: Общее время загрузки 3.21 секунд (Твиттер немного уменьшил файл, на 1/5 часть)
3. Pinterest: Общее время загрузки 0.88 секунд (Сайт преобразовал PNG в JPG, и размер уменьшился)
4. Яндекс фото: Общее время загрузки 1.84 секунд (Сайт в два раза уменьшил картинку)
5. Вконтакте: Общее время загрузки 0.7 секунд (Сайт уменьшил картинку в СЕМЬ раз!)
6. Tumblr: Общее время загрузки 1.9 секунд (Сайт уменьшил картинку в 2 раза)
7. Blogger: Общее время загрузки 3.31 секунд (Файл не уменьшился, всё как есть)
Итак, что мы имеем? А мы имеем очень интересную картину: мой ХОСТИНГ пришёл к финишу последним, что и требовалось доказать. А если учесть то, что загружая 10 фото одновременно слабый хостинг будет пыхтеть изо всех сил, то моё решение кажется оправданным.
Самый быстрый Вконтакте, но за счёт урезания фотографий. С одной стороны хорошо, с другой, как посмотреть, не будет ли портиться сильно качество? Но можно создать группу и размещать там фото и анонс статьи. По крайней мере Вконтакте можно легче собрать группу по моей тематике.
По удобству мне больше нравится Твиттер, так как там даже URL короче и взять его легко.
Pinterest хорош для сайтов, у кого фото на сайте по настоящему интересные, их могут в этой фотографической социальной сети лайкать и репостить. К тому же в этой сети открытая ссылка на само фото.
Tumblr тоже хорош, хотя бы уже тем, что там открытые ссылки. Но набрать там русскоязычных читателей не так просто.
Яндекс картинки самый плохой и не удобный вариант. Блоггер тоже очень неудобен.
Вот и закончился мой тест, осталось выбрать между Вконтакте и Твиттером для моего сайта про Линукс, да и для этого тоже.
А вы что думаете обо всем этом?
Решение задач по управляемым формам
Файлы изображений могут быть достаточно объемными, поэтому их хранение в базе может привести к сильному увеличению размеров информационной базы. Это в свою очередь приводит к разрастанию резервных копий базы, к повышенному времени создания таких резервных копий.
Поэтому достаточно часто используется такой подход – вместо изображения в информационной базе хранится только путь к файлу с картинкой, а само изображение хранится на диске в отдельном каталоге. Если возникает потребность отобразить в программе прикрепленное изображение, система обращается к файлу с картинкой на диске, выводит его на форму. Таким образом, в базе не хранится объемная информация графических файлов, а только пути к таким файлам, что существенно уменьшает размеры хранящейся в базе информации.
Однако при таком подходе требуется отдельно выполнять резервное копирование базы данных и отдельно копировать каталог на диске, где хранятся файлы изображений.
Главным недостатком такого способа хранения данных является возможность получения несогласованных данных. Файлы изображений хранятся отдельно, не в информационной базе, поэтому файл может быть удален с диска, а в базе останется ссылка на него. Также возможна обратная ситуация – элемент справочника в базе будет удален, а на диске будет храниться файл, не связанный ни с каким элементом базы данных.
На экзамене может быть предложено реализовать хранение присоединенных изображений во внешних файлах на диске. Условие задачи может быть примерно таким:
Необходимо обеспечить возможность прикреплять изображение к элементу справочника Номенклатура. Изображения следует хранить в виде отдельных файлов на диске. Прикрепленное изображение номенклатуры должно отображаться на форме элемента.
Создадим команду ЗагрузитьКартинку формы элемента справочника Номенклатура и разместим ее на форме. После выбора данной команды пользователь выбирает файл на диске, который будет прикреплен к карточке номенклатуры:
Рисунок 1 – Выбор файла картинки
Как организовать хранение изображений во внешних файлах на диске
Поскольку не требуется хранить само изображение в информационной базе, организуем хранение только имени файла, где расположено изображение, прикрепленное к карточке номенклатуры. Для этого в справочнике Номенклатура создадим реквизит ПутьКФайлуКартинки с типом Строка:
Рисунок 2 – Реквизит справочника Номенклатура для хранения пути к файлу картинки
Путь к файлу и его имя могут быть достаточно длинными, поэтому для реквизита ПутьКФайлуКартинки установим галочку Неограниченная длина:
Рисунок 3 – Свойство Неограниченная длина реквизита «ПутьКФайлуКартинки»
Как загрузить картинку для номенклатуры
Настройка формы элемента справочника Номенклатура для отображения картинки выполняется одинаково как при хранении изображений в информационной базе, так и при хранении изображений во внешних файлах. Подробно основные принципы рассмотрены в предыдущем блоке. Сейчас отметим основные отличия, характерные для хранения изображений во внешних файлах.
К сожалению, у Вас недостаточно прав для дальнейшего просмотра.
Если Вы приобрели курс, но еще не активировали токен — пожалуйста, активируйте доступ по инструкциям, высланным на Ваш email после покупки.
Если Вы не залогинены на сайте — залогиньтесь, вернитесь на эту страницу и обновите ее.
Если Вы залогинены, у Вас активирован токен доступа, но Вы все равно видите эту запись — напишите нам на e-mail поддержки.
html — Как мне хранить изображения для моего сайта?
Изменено 9 лет, 11 месяцев назад
Просмотрено 18 тысяч раз
Как правильно хранить файлы изображений в базе данных. Я использую пути к файлам для хранения изображений.
Но проблема вот в чем. Мне нужно в основном показать 3 разных размера одного изображения для моего сайта. Один будет использоваться в качестве эскиза, второй будет иметь размер около 290 пикселей * 240 пикселей, а третий будет полноразмерным (примерно 500 пикселей * 500 пикселей). Поскольку не рекомендуется уменьшать изображения с использованием элементов HTML img
, так какое же должно быть решение для этого?
В настоящее время я храню 3 изображения разного размера для одной вещи. Есть ли лучший способ?
- HTML
- изображение
Откровенно говоря, правильный способ хранения изображений в базе данных — не хранить их в базе данных. Храните их в файловой системе и держите БД ограниченным путем.
В конце концов, вы говорите о месте для хранения. Это реальная проблема. Если вы храните несколько копий одного и того же файла с разным разрешением, это займет больше места, чем хранение одной копии файла.
С другой стороны, если вы храните только одну копию файла и масштабируете ее динамически, вам не нужно место для хранения, но вместо этого требуется больше вычислительной мощности.
И, как вы уже сказали в вопросе, отправка полноразмерного изображения каждый раз дорого обходится с точки зрения пропускной способности.
Таков компромисс; дисковое пространство на вашем сервере по сравнению с работой процессора по сравнению с затратами на пропускную способность.
Дело в том, что самая дешевая из этих трех вещей — место для хранения. Поэтому вам следует хранить несколько копий файлов на вашем сервере.
Это также решение, которое обеспечит вам наилучшую производительность, что во многих отношениях является даже более важным моментом, чем прямые затраты.
Что касается хранения путей к файлам, я советую давать масштабированным версиям предсказуемые имена со стандартным префиксом или суффиксом по сравнению с исходным файлом. Это означает, что вам нужно иметь только одно имя файла в базе данных; вы можете просто добавить префикс для соответствующей версии запрошенного изображения.
Нет ничего плохого в сохранении нескольких версий одного и того же изображения.
В идеале вы хотите еще больше — @2x для экранов Retina.
Вы можете использовать сценарий на стороне сервера для динамического создания меньших, но в зависимости от уровня трафика это может быть плохой идеей.
На самом деле вы жертвуете объемом памяти и скоростью в обмен на более высокую загрузку ЦП и ОЗУ, чтобы генерировать их на лету — в зависимости от вашей ситуации это может быть хорошим компромиссом, а может и нет.
4 Согласен с Риком, вы можете хранить фотографии разных размеров в соответствии с вашими бизнес-требованиями. Вы должны хранить изображение в папке на сервере и хранить его местоположение в базе данных. Создайте иерархию в папке и храните изображения с низким разрешением внутри папок, чтобы вы всегда могли ссылаться на них только по одному адресу.
вы можете сделать это в своем config
создайте папки .233240 и .540540 и сохраните в них изображения с одинаковыми именами, чтобы вы могли легко получить к ним доступ.
Зарегистрируйтесь или войдите в систему
Зарегистрируйтесь с помощью Google Зарегистрироваться через Facebook Зарегистрируйтесь, используя электронную почту и парольОпубликовать как гость
Электронная почтаТребуется, но никогда не отображается
Опубликовать как гость
Электронная почтаТребуется, но не отображается
Нажимая «Опубликовать свой ответ», вы соглашаетесь с нашими условиями обслуживания и подтверждаете, что прочитали и поняли нашу политику конфиденциальности и кодекс поведения.
c# — Как мне хранить изображения для моего веб-сайта/приложения?
Задавать вопрос
спросил
Изменено 1 год, 2 месяца назад
Просмотрено 1к раз
Моя команда и я (все студенты, это проект колледжа) создаем программное обеспечение, которое состоит из двух интерфейсов (веб-сайт и приложение), подключенных к серверу через API. У нас есть сущность-пользователь в этом программном обеспечении, и одно из его свойств — 9.0013 image
Что делать в таких случаях? Какая лучшая практика? (все компоненты будут развернуты, поэтому локальное хранение на самом деле не вариант).
(Мы имели в виду получить какой-то сторонний сервис, куда мы могли бы загружать изображения и просто хранить ссылку в БД, но возможно ли это? Это нормально?).
- С#
- HTML
- .net
Вы можете использовать облачное хранилище, например
- Amazon S3 (https://aws.amazon.com/s3/)
- Google Cloud Bucket (https://cloud.google.com/storage/docs/creating-buckets)
- Хранилище Microsoft Azure (https://learn.microsoft.com/en-us/azure/storage/common/storage-introduction)
У них есть несколько бесплатных для экспериментов/обучения, но вы также должны знать о взимаемых сборах после некоторых определенных ограничений использования. Они используют облачные вычисления, поэтому вам не нужно беспокоиться о производительности.
Еще один вариант: вы можете создать собственный сервер изображений и размещать изображения непосредственно на своем веб-сайте. Преимущества могут быть следующими:
- Наличие такого же прямого подключения к вашему веб-сайту через домены (иногда быстрее, чем в облаке)
- Вы можете гибко управлять размерами/типами изображений в соответствии с вашими запросами.