Comments 53
А что-нибудь известно по ресурсам, требуемым для работы primitive и генерации простейшего svg из 10 фигур? Быстрее оно, чем генерация миниатюр через imagemagick?
А по размеру SVGO явно получше будет с <1kb против нынешних прейсхолдеров в 2kb. Не бесплатно же нам даётся эта экономия места, скорее всего в обмен на ЦПУ.
можно же и на бэке сделать. Поставить чтобы аватарку нельзя было менять чаще чем раз в 5(10,20, 100500) раз в минуту или делать плейсхолдеры, только когда она "продержалась" 1(2,3,7, 14) дней.
Отправлять svg гораздо дешевле
Действительно, я какую-то глупость написал. Думал что под бесполезной работой подразумевается "генерация svg на фронте", но только сейчас понял что для этого нам нужно само изображение "=.=
По поводу отображения svg vs jpeg — это стандартная дилемма: память vs вычисления.
С одной стороны у большинства пользователей уже есть быстрый домашний и (иногда) мобильный интернет, в кафе и торговых центрах есть Wi-Fi и загрузить лишнюю маленькую jpeg не составит труда, но с другой стороны браузеру итак есть что грузить, а тут ещё "лишние" jpeg файлы, пускай и небольшого размера.
С другой стороны вычислительные мощности бОльшей части устройств смогут справиться с выводом 10 фигур, что будет очень кстати для пользователей мобильных устройств.
Да это решение — не панацея, но оно имеет свои плюсы (например стилизация соцсети/сервиса). Думаю особенно красиво это смотрелось бы с специальной задержкой перед показом картинки и последовательным превращением фигур в фотографию.
В остальных случаях, как и сказал TimsTims можно использовать прогрессивный JPEG
В случае с Progressive JPEG, лаг между пустым местом и хоть чем-то напоминающим картинку будет несколько выше.Отнимаем несколько десятых секунды на отрисовку SVG, иэ тот лаг уже компенсируется при «нормальном» интернете. Даже более того, небольшое зависание браузера и компьютера (100% CPU) перевешивает чашу весов в пользу JPEG.
SVG из статьи выигрывает только когда у пользователя очень плохой канал интернета(или ваш сайт очень жирный), и ему загрузить 100% CPU на пару секунд выгоднее, чем ждать +60 секунд на полную прогрузку.
загрузить 100% CPU на пару секундНе демонизируйте SVG. Во-первых, Primitive на выходе даёт треугольники, отрисовка которых — самое «дешёвое» после цветного прямоугольника, а во-вторых — отрисовка SVG во всех современных браузерах делается с аппаратным ускорением (в том же Хромиуме доступно аж с 2011 года).
2. Большая часть этого svg — текст, который можно было бы просто закодировать как координаты, прозрачности и цвета для треугольников. Если каждый треугольник описывается 6 u16 и цветом, то это 16 байт на треугольник. 100 треугольников — 1600 байт. Если же обнаглеть и разрешить огрублять позции треугольников до байта, то это 10 байт на треугольник, 100 треугольников — 1кб без сжатия.
Но у меня вопрос: если на странице 30 превьюшек, то сколько мегафлопов будет сожрано у пользовательской батарейки в процессе «предрендеринга»?
Меня беспокоил такой же вопрос.
Решил проверить, сделал примитивный тест на codepen, который просто создает svg с n количеством треугольников.
Браузер на компьютере подвисает на 3-4 секунды от 100 000 треугольников, после чего функционирует нормально.
У телефона такие же проблемы начинаются с 10 000 треугольников (Xiaomi Redmi 3S)
Я бы сказал, что дофига.
Хороший вопрос.
Первая моя мысль мысль: выгода была бы такой, что ей можно было бы пренебречь, потому что цикл из 10 000 элементов проходится относительно легко.
Вторая что JS страдает при каждом добавлении нового элемента в DOM, поэтому выгода могла быть большой.
Третья: готовым файлом — это как?
Третья: готовым файлом — это как?placeholder.svg
Не знаю я, как это в вебе правильно делать. Вероятно как-то так habrahabr.ru/company/edison/blog/342848/?reply_to=10536428#comment_10531650
Вторая что JS страдает при каждом добавлении нового элемента в DOM, поэтому выгода могла быть большой.
По-моему, это было актуально 2-3 года назад.
Сейчас что добавление нового элемента в DOM, что генерация одним большим куском работают одинаково быстро.
Но у меня вопрос: если на странице 30 превьюшек, то сколько мегафлопов будет сожрано у пользовательской батарейки в процессе «предрендеринга»?
Тут кстати есть интересный момент. Если мы знаем, что наша svg содержит только одноцветные треугольники, то отрисовать это с помощью GPU расплюнуть. Поэтому если заморочится и написать JS рисующий через WebGL запросто можно получить ощутимый профит, и не сильно жечь батарею.
Кстати, для вывода 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]
Кого это заинтересует + найдётся время изучить предложенные алгоритмы генерации (с текущими исходниками) — думаю там есть что улучшить и написать хорошую статью.
Я таки думал очевидно, что вопрос про фреймворки и библиотеки, ибо я не знаток Codepen, ведь вполне было возможно что там где-то в настройках используемые библиотеки подключаются. Я бегло посмотрел код, не нашёл ничего из того же jQuery, но всё же решил уточнить.
SVG-картинка из треугольников — теоретически интересно, практически смысла ноль. Они пишут, что 100 треугольников после оптимизации весят около 5 кб. Я прикинул: аналогичный вес имеет PNG-картинка размером порядка 100-120px по каждой стороне, которая дает отличное представление об изображении и намного меньше ест ресурсы. Вообще говоря, 100px для LQIP — это сильно избыточно, обычно берут что-то в пределах 20-50px.
SVG-силуэты — с сугубо утилитарной точки зрения тоже очень спорно, но тут можно совместить практичность и эстетику, создав интересный дизайнерский эффект. Но опять же не универсально.
Мой выбор — банальный растровый LQIP весом не более 1 кб, причем даже без блура.
Двухцветный png 2.5 Кб. Выглядит пикселезировано.
Двухцветный webp 2.3 Кб. Выглядит пикселезировано.
Четырехцветный png 3.5 Кб. Выглядит сглажено.
Четырехцветный webp 4.7 Кб. Выглядит сглажено.
Двухцветный png в два раза больше приведенного разрешения на странице 6 Кб.
Двухцветный lossless двойного разрешения webp 5.7 Кб.
Получается с монохромным изображением, которое очень хорошо сжимается, эти растровые форматы работают намного лучше. Они меньше нагружают процессор. Пайплайн работы с ними более отлажен и надежен.
Хотя сравнение с треугольниками вероятно будет не победоносным для растра.
т.к. нужно загрузить либу генерации svg и потратить время/ресурсы на собственно генерацию
Использование SVG в качестве Placeholder’a