How to become an author
Search
Write a publication
Pull to refresh

Comments 53

Статья отличная, за перевод спасибо. Но твиты картинками… За что вы так с нами? :)
Total votes 7: ↑7 and ↓0+7
Как по мне, так вариант с простым векторным svg без гаусса лучше всего смотрится в роли плейсхолдера.
А что-нибудь известно по ресурсам, требуемым для работы primitive и генерации простейшего svg из 10 фигур? Быстрее оно, чем генерация миниатюр через imagemagick?
Total votes 2: ↑2 and ↓0+2
UFO just landed and posted this here
Вот потому и вопрос. По ощущениям Делоне явно сложнее, чем свёртка по пикселям, но всё может решить реализация. Primitive на Go vs imagemagick на C.
А по размеру SVGO явно получше будет с <1kb против нынешних прейсхолдеров в 2kb. Не бесплатно же нам даётся эта экономия места, скорее всего в обмен на ЦПУ.
Total votes 1: ↑1 and ↓0+1
SVG ещё и deflate'ом пожмётся при передаче, кроме этого.
This comment wasn’t rated yet0
Вообще я бы подумал в сторону хранения вектора в виде набора инструкций для 2D Canvas в бинарном формате. Хотя, конечно, SVG удобнее заменять потом на реальную картинку.
This comment wasn’t rated yet0
Я уж думал, что у меня бразуер сломался. Твиты в виде картинок оказались слишком жестокими для меня.
Total votes 4: ↑4 and ↓0+4
UFO just landed and posted this here
Если очень коротко, там можно писать сообщения и читать их. Подписываетесь на людей или темы которые вам интересны, и читаете.
Total votes 5: ↑5 and ↓0+5
+1 в копилку способов нагрузить браузер бесполезной работой.
Total votes 9: ↑8 and ↓1+7

можно же и на бэке сделать. Поставить чтобы аватарку нельзя было менять чаще чем раз в 5(10,20, 100500) раз в минуту или делать плейсхолдеры, только когда она "продержалась" 1(2,3,7, 14) дней.
Отправлять svg гораздо дешевле

Total votes 2: ↑1 and ↓10
Он имел ввиду про то, что отрисовка SVG относительно трудозатратная задача, в отличии от тупого вывода jpeg (как ни странно).
Total votes 9: ↑9 and ↓0+9

Действительно, я какую-то глупость написал. Думал что под бесполезной работой подразумевается "генерация svg на фронте", но только сейчас понял что для этого нам нужно само изображение "=.=


По поводу отображения svg vs jpeg — это стандартная дилемма: память vs вычисления.
С одной стороны у большинства пользователей уже есть быстрый домашний и (иногда) мобильный интернет, в кафе и торговых центрах есть Wi-Fi и загрузить лишнюю маленькую jpeg не составит труда, но с другой стороны браузеру итак есть что грузить, а тут ещё "лишние" jpeg файлы, пускай и небольшого размера.
С другой стороны вычислительные мощности бОльшей части устройств смогут справиться с выводом 10 фигур, что будет очень кстати для пользователей мобильных устройств.


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


В остальных случаях, как и сказал TimsTims можно использовать прогрессивный JPEG

Total votes 2: ↑2 and ↓0+2
А что мешает в качестве плейсхолдеров использовать те же инлайнутые JPG или PNG?
Total votes 2: ↑2 and ↓0+2
На сколько я понял, основной упор делается на то, что плейсхолдеры можно встроить непосредственно в саму страницу, и они отобразятся сразу, до того как браузер начнёт грузить реальные картинки. В случае с Progressive JPEG, лаг между пустым местом и хоть чем-то напоминающим картинку будет несколько выше.
Total votes 4: ↑4 and ↓0+4
Думаю, при использовании server push, лаг будет незаметен
Total votes 1: ↑1 and ↓0+1
UFO just landed and posted this here
В случае с Progressive JPEG, лаг между пустым местом и хоть чем-то напоминающим картинку будет несколько выше.
Отнимаем несколько десятых секунды на отрисовку SVG, иэ тот лаг уже компенсируется при «нормальном» интернете. Даже более того, небольшое зависание браузера и компьютера (100% CPU) перевешивает чашу весов в пользу JPEG.

SVG из статьи выигрывает только когда у пользователя очень плохой канал интернета(или ваш сайт очень жирный), и ему загрузить 100% CPU на пару секунд выгоднее, чем ждать +60 секунд на полную прогрузку.
Total votes 2: ↑1 and ↓10
загрузить 100% CPU на пару секунд
Не демонизируйте SVG. Во-первых, Primitive на выходе даёт треугольники, отрисовка которых — самое «дешёвое» после цветного прямоугольника, а во-вторых — отрисовка SVG во всех современных браузерах делается с аппаратным ускорением (в том же Хромиуме доступно аж с 2011 года).
This comment wasn’t rated yet0
Мне кажется описанный метод лучше с точки зрения дизайна. Понятно что не стоит пихать его кругом, но кое где он может прийтись очень даже в тему
This comment wasn’t rated yet0
Нет. Прогрессивная не работает. Она требует второго запроса на сервер ради хоть чего-то. А плейсхолдер отдается вместе с первым запросом html в теле. Не помню даже где я хоть раз видел у кого она работает.
This comment wasn’t rated yet0
глупость какую-то написал и не ясно почему…
This comment wasn’t rated yet0
UFO just landed and posted this here
1. 1-4к — этого вполне достаточно для jpeg-превьюшки терпимого качества.
2. Большая часть этого svg — текст, который можно было бы просто закодировать как координаты, прозрачности и цвета для треугольников. Если каждый треугольник описывается 6 u16 и цветом, то это 16 байт на треугольник. 100 треугольников — 1600 байт. Если же обнаглеть и разрешить огрублять позции треугольников до байта, то это 10 байт на треугольник, 100 треугольников — 1кб без сжатия.

Но у меня вопрос: если на странице 30 превьюшек, то сколько мегафлопов будет сожрано у пользовательской батарейки в процессе «предрендеринга»?
Total votes 7: ↑7 and ↓0+7

Меня беспокоил такой же вопрос.
Решил проверить, сделал примитивный тест на codepen, который просто создает svg с n количеством треугольников.
Браузер на компьютере подвисает на 3-4 секунды от 100 000 треугольников, после чего функционирует нормально.
У телефона такие же проблемы начинаются с 10 000 треугольников (Xiaomi Redmi 3S)

Total votes 2: ↑2 and ↓0+2
Итого: 30 превьюшек по 100 треугольников делают нам 3000 треугольников. То есть примерно секунду «подвисания» браузера мобильного телефона или 0.3с десктопа (100% CPU, насколько я понимаю).

Я бы сказал, что дофига.
Total votes 7: ↑7 and ↓0+7
Ламера вопрос: а если ту же свгшку готовым файлом вставить, а не добавлять треугольники в цикле по одному, разве быстрее не будет?
Total votes 2: ↑2 and ↓0+2

Хороший вопрос.
Первая моя мысль мысль: выгода была бы такой, что ей можно было бы пренебречь, потому что цикл из 10 000 элементов проходится относительно легко.
Вторая что JS страдает при каждом добавлении нового элемента в DOM, поэтому выгода могла быть большой.
Третья: готовым файлом — это как?

Total votes 1: ↑1 and ↓0+1
Вторая что JS страдает при каждом добавлении нового элемента в DOM, поэтому выгода могла быть большой.

По-моему, это было актуально 2-3 года назад.
Сейчас что добавление нового элемента в DOM, что генерация одним большим куском работают одинаково быстро.

Total votes 1: ↑1 and ↓0+1
Но у меня вопрос: если на странице 30 превьюшек, то сколько мегафлопов будет сожрано у пользовательской батарейки в процессе «предрендеринга»?

Тут кстати есть интересный момент. Если мы знаем, что наша svg содержит только одноцветные треугольники, то отрисовать это с помощью GPU расплюнуть. Поэтому если заморочится и написать JS рисующий через WebGL запросто можно получить ощутимый профит, и не сильно жечь батарею.
Total votes 1: ↑1 and ↓0+1

Кстати, для вывода data-uri SVG изображений можно не кодировать в Base64, достаточно закодировать SVG в виде Url, то есть прогнать через какой-нибудь httpencode


<img style="background: url(data:image/svg+xml;utf8,[svg_http_encoded]">

Это позволит во-первых, немного уменьшить размер текста, во-вторых, браузеру не нужно будет выполнять декодирование base64, что может быть медленным, в-третьих, это лучше сжимается gzip'ом. Если кодировка не важна, можно ее опустить: data:image/svg+xml,[svg_http_encoded]

Total votes 3: ↑3 and ↓0+3
Насколько я помню, в IE11 есть странный глюк: если не кодировать в base64, это не будет работать.
Total votes 1: ↑1 and ↓0+1

Работает вплоть до IE9, было бы круто ели бы вы показали пример если что-то действительно не работает, чтобы не наступить на грабли, если что.

Total votes 1: ↑1 and ↓0+1
UFO just landed and posted this here

А какая разница, мы httpencoded засунем внутрь url() или base64? Но, в целом, ограничение на размер data:URL было у IE8(32кб) и какой-то старой Opera.

Total votes 1: ↑1 and ↓0+1
Извините, я сейчас не так пристально слежу за темой веб-разработки, не знал что это уже не актуально.
Total votes 1: ↑1 and ↓0+1
Статья интересная, но на превьюшке для затравки алгоритм отработал странно. Вместо ожидаемого одного треугольника, видим два.
image
Кого это заинтересует + найдётся время изучить предложенные алгоритмы генерации (с текущими исходниками) — думаю там есть что улучшить и написать хорошую статью.
Total votes 3: ↑1 and ↓2-1
Ну не знаю, мне вполне видится, что там не обойтись одним трехугольником
Total votes 4: ↑4 and ↓0+4
Вы прям как эталонный хабровчанин отвечаете.

Я таки думал очевидно, что вопрос про фреймворки и библиотеки, ибо я не знаток Codepen, ведь вполне было возможно что там где-то в настройках используемые библиотеки подключаются. Я бегло посмотрел код, не нашёл ничего из того же jQuery, но всё же решил уточнить.
Total votes 3: ↑3 and ↓0+3
Заливка доминирующим цветом — абсолютно бесполезная ерунда.

SVG-картинка из треугольников — теоретически интересно, практически смысла ноль. Они пишут, что 100 треугольников после оптимизации весят около 5 кб. Я прикинул: аналогичный вес имеет PNG-картинка размером порядка 100-120px по каждой стороне, которая дает отличное представление об изображении и намного меньше ест ресурсы. Вообще говоря, 100px для LQIP — это сильно избыточно, обычно берут что-то в пределах 20-50px.

SVG-силуэты — с сугубо утилитарной точки зрения тоже очень спорно, но тут можно совместить практичность и эстетику, создав интересный дизайнерский эффект. Но опять же не универсально.

Мой выбор — банальный растровый LQIP весом не более 1 кб, причем даже без блура.
Total votes 5: ↑4 and ↓1+3
UFO just landed and posted this here
Силуэты в svg со страницы с примером занимают 32.9 Кб, после сжатия 11.7 Кб.
Двухцветный png 2.5 Кб. Выглядит пикселезировано.
Двухцветный webp 2.3 Кб. Выглядит пикселезировано.
Четырехцветный png 3.5 Кб. Выглядит сглажено.
Четырехцветный webp 4.7 Кб. Выглядит сглажено.
Двухцветный png в два раза больше приведенного разрешения на странице 6 Кб.
Двухцветный lossless двойного разрешения webp 5.7 Кб.

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

Хотя сравнение с треугольниками вероятно будет не победоносным для растра.
This comment wasn’t rated yet0
Интересная постобработка. Простенько, как говорится, и со вкусом.
This comment wasn’t rated yet0
идея отличная, но хотелось бы понимать с какого количества/размеров картинок эти способы дают профит
т.к. нужно загрузить либу генерации svg и потратить время/ресурсы на собственно генерацию
This comment wasn’t rated yet0
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr