Самые распространенные ошибки в дизайне сайтов 20-х годов

[mihas]

Сегодняшний уровень развития компьютерной техники и средств визуализации позволяет видеть то, что ранее просто не было заметно, что просто не имело значения на заре интернета. А сегодня имеет значение колоссальное.
Так порой даже крупные известные компании, в том числе и полиграфические, ужасно подставляются сегодня, когда у их корпоративного сайта на лбу написано образно говоря, что сайт сделан из мусора тремя калеками в темном чулане. Очень наглядно может быть заметно, что разработчики в жизни не прикасались к современным компьютерам и никогда не видели современных мониторов.

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

1. Цветовой охват и элементы разметки html без цветового профиля. Для сайтов для полиграфистов и о полиграфии это также актуально, потому что клиентура типографии - издатели, дизайнеры - как правило работают на профессиональном оборудовании, а не самом дешевом. Зачастую при просмотре сайта мы имеем дело с маленьким цветовым охватом sRGB, 1996 года разработки. Он используется в офисной технике и в устаревшем оборудовании, однако, пока все еще считается стандартом де-факто для интернета, но эта эпоха скоро закончится. Есть охват подороже и побольше - P3, он используется в современных мультимедийных экранах и во всей недешевой технике Apple для профессионалов.

Сравнение охватов sRGB и Dispalay P3 https://cielab.xyz/xylocus.php

• 590.13 КБ • 4035 просмотров

P3 - это мейнстримный охват на сегодня при разработке хороших мониторов средней ценовой категории для большинства, для профессионалов в любой графике, игр и мультимедиа, подходит всем и по цене и по качеству. И есть самый дорогой, но чуть меньший, чем P3, охват Adobe RGB, которым пользуются разработчики визуального контента в полиграфии, в специальном софте с безупречным колорменеджментом. Я назвал три стандартных охвата на рынке мониторов. И еще бывает такая попса с охватом типа 65% от и так крохотного sRGB, для офисных приложений, в дешевых дисплеях. Сравнить охваты графически между собой или непосредственно со своим дисплеем можно тут.

Чем чревато для разработчика создание цветовых палитр сайта без цветового профиля в том случае, если он никогда не видел результат своей разработки на профессиональном мониторе Adobe RGB ценой около 100 тысяч рублей и выше в разных браузерах, когда разработчик видел свою разработку лишь на дешманском дисплее с небольшим цветовым охватом стандарта 96 года и меньше? От некоторых цветовых палитр моментально "вытекают глаза" на профессиональном мониторе; за доли секунды после открытия такого сайта профессиональный разработчик визуального контента буквально слепнет минут на 10, это словно удар кулаком прямо в глаз. Нельзя делать для веб сверхнасыщенные цвета без цветового профиля (а таких html-элементов без цветового профиля полно), которые могут быть неверно интерпретированы браузером по цвету. В браузерах все не очень хорошо с колорменеджментом, это вам не Фотошоп. Когда цветокорректор получает кулаком в глаз от разработчика сайта с дешманским монитором уровня 65% от охвата крохотного sRGB, он никогда больше не войдет на сайт данного предприятия, после такого экстрима требуется время, чтобы адаптация зрения восстановилась. Не буду давать ссылку, но мне так в глаз один раз врезала с ноги крупная типография. Вот уж от кого не ожидал, что при тиражах-милионниках у полиграфической компании нет возможности обеспечить разработчика своего сайта профессиональным монитором!

Внедряйте цветовой профиль в картинку. Если элемент html не поддерживает описания профилем, трижды передумайте делать его сверхнасыщенным по цвету. И проверьте хотя бы для начала у друзей на мониторе Adobe RGB, как ваше html-творение выглядит без колорменеджмента в огромном профессиональном охвате разработчика. Или хотя бы в мейнстримном сегодня большом мультимедийном охвате P3.

Несложная утилита с графическим интерфейсом CSS Color Manager позволяет добавить к имеющейся цветовой разметке hex (формат цвета для WEB по типу #0F0 или #00FF00) в стандарте sRGB также и дополнительную разметку @media color-gamut tag для мониторов большого цветового охвата Display P3 и Rec. 2020.

Если вы хотите, чтобы ваш цвет одинаково отображался на мониторах как с маленьким цветовым охватом sRGB, так и с бОльшими - просто добавьте @media color-gamut tag в качестве дополнительной разметки к уже имеющейся. А утилита CSS Color Manager верно пересчитает весь имеющийся цвет sRGB в разметке hex в два дополнительных популярных стандарта - Display P3 и Rec. 2020. Пример работы CSS Color Manager.

Иллюстрация png с прозрачностью в превьюшке высокого разрешения на странице с этого форума (тема Куинджи) просто для иллюстрации, можете испытать по Ctrl+


Штатная превьюшка форума шириной 320 пикселей для старых мониторов

2. Разрешение и детализация. Тег srcset для имиджей придумали после того, как разрешение типичных мониторов увеличилось до 2K, 4K, 8K, против пока еще привычных, крохотных Full HD 1920х1080, когда пиксель на экране стал меньше, пикселей при той же диагонали стало больше и потребовалось масштабирование в операционных системах. Так, сегодня типичное мейнстримное масштабирование на обычных типичных UHD 4K мониторах, с типичной диагональю около ~30 дюймов, составляет обычно 150%-200%. На таком современном и главное, вполне типичном популярном мониторе UHD, чуланная разработка сайта из трешовых фоток низкого разрешения выглядит очень мыльной, словно вместо картинок высокого разрешения подгружена превьюха времен 90-х годов модемного интернета. Так происходит от того, что разработчик на устаревшем железе просто не видит качество детализации картинки выше разрешения 72-96 пикселей на дюйм. А современный потребитель картинки в браузере видит с разрешением минимум 144 пикселя на дюйм и выше.

Разработчику сайта без современного монитора UHD просто не видно, что за мыло он создает на своем устаревшем железе. Те компании, что все же купили своему веб-разработчику нормальный современный монитор, сразу понимают, что без тега srcset для картинок с их сайта выглядит сайт просто позорно замылено. Тег srcset позволяет добавить для каждого img варианты с разным разрешением. На сегодня достаточно дополнительного двукратного разрешения для типичных мониторов 4K, и четырехкратного для мониторов будущего 8K. Обладателю старого монитора будет подгружена картинка самая легкая с традиционным маленьким разрешением, обладателям современных мониторов - картинка удвоенного разрешения. Ее надо создать и прописать в коде сайта. Ну и если картинка позволяет, конечно не пренебрегать векторными изображениями SVG, которые могут масштабироваться без счету кратности сколько угодно. Неплохо с вектором работал flash, но flash заигнорили, как потенциально опасную технологию. Кстати тут на форуме я немного дописал код за разработчиками phpbb, чтобы обладателям современных мониторов, айфонов и смартфонов показывалась превьюха картинки повышенного разрешения в теле топика на любой странице форума.

Пример плохой разработки сайта. WTF • ?

• 1.25 МБ • 4035 просмотров

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

3. Сжатие с потерями и без потерь. Тут все просто, jpeg жмет с потерями, png - без потерь. Когда артефакты жпег заметны на изображении - это выглядит дешевой поделкой, выглядит краденным изображением из 90-х, а не оригинальным изображением 2020-х.
Для фотографий жпег актуальнее, хотя бы не жмите его компрессию ниже уровня 9-11 фотошопа (по шкале от 0 до 12). FastStone и особенно XnView жмут экономнее фотошопа. 93% уровень сжатия (где 100% - максимальный размер и максимальное качество) - обычно во всех программах приводит к хорошей компактности и потери еще не заметны.

gif имеет смысл использовать для анимашек

• 95.86 КБ • 4035 просмотров

Для бизнес-графики, техногенных скриншотов актуальнее png вообще без потерь в качестве и часто при крохотном размере. Порой, если это не пестрая фотка, png безупречного качества может весить ощутимо меньше визуально побитого компрессией жпега. Плюс png поддерживает прозрачности и полупрозрачности, что часто бывает полезно в оформлении сайта. Фотошоп жмет png не плохо, но есть более мощные программы для сжатия png, я пользуюсь Pingo (из командной строки)* или она же pinga с графическим интерфейсом. Пережимает без потерь png очень плотно, от 10% до 40% экономии трафика и соответственно скорости загрузки страницы относительно самого плотного сжатия без потерь png фотошопом. Ну и если вы записываете компактный PDF - я бы рекомендовал внутри него сжатие ZIP без потерь для изображений, а не JPEG даже с самым высоким качеством.

* Батник высокого сжатия без потерь для pingo:

Код: Выделить всё

pingo -s9 *.png
pause:

Этузиасты могут попробовать Efficient-Compression-Tool или ECT c максимальным из возможных сжатий, но это долго:

Код: Выделить всё

ect -9 -strip --strict --disable-jpg --allfilters-b file.png

Сжатие lossy с потерями и losless без потерь хорошо проиллюстрировать не только изображениями, но даже музыкой. MP3 с низким битрейтом и потерями остались в 90-х, сейчас популярны losless форматы компрессии музыки без потерь ape, flac и иже с ними не только среди меломанов, но и среди обычных слушателей. То же и с визуальной информацией: современный пользователь менее терпим к потерям и артефактам жпег, к низкому разрешению, к неверному колорменеджменту, нежели пользователь модемного соединения 90-х. Но и гигабитные скорости пока не позволяют совсем не думать о размерах в мегабайтах. Помимо png появляются и новые форматы упаковки изображений высокого разрешения типа HEIC от Aplle, которые стараются придумать максимальную компрессию без потерь. Проблема в том, что тот же HEIC пока браузерами не поддерживается и слишком сложен для процессоров Intel и NVidia: но этот нативный свой формат айфоны щелкают как орешки. Тот случай, когда алгоритм сжатия ориентирован на архитектуру процессора. А например JPEG 2000 пока для любых процессоров тяжеловат. Вот с компрессией видео H.264 и H.265 по-моему все удачно складывается, все современные и даже не очень новые GPU справляются хорошо без видимого напряжения в реальном времени.

К примеру, вот две техногенных картинки из сети, одна весит меньше килобайт и качественнее, вторая весит больше килобайт и качества низкого. Какой-то балбес веб-дизайнер тупо не глядя пережал png-оригинал жпегом, и она пошла гулять по сети с пониженными требованиями к качеству, в безобразном виде, с артефактами жпег, больше по трафику и ниже по качеству. Не делайте так, пожалуйста. Я случайно, поскольку много интересовался темой, набрел на хорошую картинку в оригинале, посмотрите сами на хорошем мониторе, приблизьте и сделайте выводы:
хорошая и мало килобайт весит (оригинал png, не сразу разыскал)
плохая и много килобайт весит (бессмысленная пережатка в жпег с артефактами)

[mihas]

Просто соображение пришло в голову. На днях делал небольшой проектик с нуля - писал руководство пользователя к программе. Со скриншотами, с оптимизацией и под смартфоны, и под огромные мониторы. И я просто даже не стал делать отдельные скрины под низкие разрешения старых экранов. Сразу с 4-кратным уменьшением загнал скрины в проект без srcset, а для всех, на будущее, и под 4K и под 8K годится. Все равно техногенные скрины PINGO жмет плотно, на том, что я их буду уменьшать под старые мониторы особо не сэкономишь, да и кому нужна слепая превьюха с текстом, который не прочитаешь? Короче, 4-кратную картинку загоняешь целиком в верстку сайта с обозначенными размерами и не паришься еще много лет, что разрешение и детализация может устареть. А чтобы не сильно жрать трафик в проекте с большим кол-вом картинок - жмем их как только можно плотнее, хоть тем же pingo, без потерь.

Мне мой один знакомый продавец серверов говорит: да не парься ты трафиком, клади картинки хоть 8-мегабайтные, современные сервера и не такое выдерживают, гигабиты, терабиты, чего морочиться каким-то там сжатием? А я думаю, все хорошо в меру: лучше я повыше качество и детализацию сделаю, но не пожалею времени поплотнее сжать без потерь, чем буду выкладывать изображения как попало, и при мобильном трафике это может стать заметно в проектах, где картинок сильно больше одной на странице. Не на стороне сервера заметно, на стороне клиента. Типичный современный продвинутый гигабит приходит от провайдера только на хороший роутер при хорошем тарифе, типичная WiFi сеть на этом роутере - более чем в 10 раз медленнее. Так что о трафике и о сжатии стоит думать все же, затевая проект с повышенным разрешением и детализацией 8K ближайшего будущего.