ProgerSoft, уверенность — понятие относительное, всегда рад ошибиться касательно технологии, иначе нет развития. Касательно NanoCSS был уверен не в плане скорости, а именно в результатах на выходе (сжатие, объединение и т. п.).
NanoCSS пока ничего ни разу не сломал, что случилось, к примеру, с CleanCSS, но вполне возможно, что это мои косые руки.
Вообще, вы весьма интересную тему подняли.
Сейчас товарищ sim3x прислал ссылку (первую) на сводную таблицу результатов, есть повод задуматься. Надо тестировать.
ProgerSoft, да, пробовал как раз с level 2 (последний, как помню), ещё комбинировал другие параметры, но остановился на NanoCSS, результаты получались лучше в плане уровня сжатия кода. В любом случае, нахожусь сейчас в поисках инструментов лучше, чем NanoCSS.
Единственная проблема, которую заметил у NanoCSS, это ошибка пирсинга свойства calc(80px + env(safe-area-inset-bottom)). Решилось обособлением env() скобками: calc(80px + (env(safe-area-inset-bottom)));
sim3x, в этом вы можете быть правы. Но вы бы могли тоже привести аналоги, иначе не понятно, с чем сравнить. С технологиями не рождаются и живут всю жизнь. Я с удовольствием сменю NanoCSS на что-то более эффективное.
sim3x, но вы не учитывает великий и могучий фактор пользователей, которые заходят на сайт даже с IE11, Safari 10 и т. п.
Исходники всякого разного могут быть и 30 МБ. Вот у меня лежат исходники стилей целого веб-приложения с кучей всего — около 8 Мб. Обычные сайты — это около 500 Кб CSS, так что вполне нормальный инструмент.
sim3x, наверное, для лучшей поддержки браузеров? К примеру, perspective без префикса на iOS 10.X вызывает проблемы с z-index в ряде случаев, ну и тому подобное. В США, по статистике компании, где я работаю, нашими веб-сервисами с устройств на iOS 10 пользуются ~9% людей.
Autoprefixer надо, конечно, не тупо прогонять «last 20 versions», а настраивать его (+ оставлять функциональные комментарии для него в CSS-разметке). Transition'ы, конечно, префиксить не нужно, если нет цели поддержки древних браузеров.
NanoCSS работает быстро, если говорить на примере одного общего CSS размером как 100 Кб, так и 800+ Кб. Если куча мелких CSS (~90–100 штук) — примерно так же, как один.
Сборка из ~100 файлов LESS в один CSS + Autoprefixer + NanoCSS = 4–5 секунд на Macbook Pro 15 (2017). Общий размер CSS после этого — около 400 Кб. LESS-логика не особо сложная.
Но опять же скорость зависит от многих условий. Бывает и быстрее сборка, бывает медленнее.
Михаил Проскурин, не всегда так. Есть другой тип дизайна, — полноэкранный, без ограничения ширины зоны контента. Всё зависит от дизайна. Ну или же, к примеру, есть полноэкранный дизайн, но с ограничением максимальной ширины для сверхшироких экранов:
width: 100;
max-width: 2560px;
Всё зависит от дизайна. Вот возьмите, к примеру, divan.ru. Там местами область контента ограничена по ширине (текстовые блоки), но в целом, область контента занимает всю ширину окна (хоть 2560 пикселей).
Hary, обязательно учитывайте хотя бы скроллбар, поэтому не надо 1366-ти. Но всё зависит от дизайна. Если у вас контейнер с контентом, к примеру, 1200 пикселей, то это уже не важно, 1349 или 1366.
Кроме того, не согласен со словами первого комментатора. Ширина контейнера с контентом может быть во всю ширину макета. Всё зависит от дизайна.
Вот возьмите, к примеру, divan.ru. Там местами область контента ограничена по ширине (текстовые блоки), но в целом, область контента занимает всю ширину окна (хоть 2560 пикселей).
Стоит отметить, что orientation в CSS не зависит от реального положения устройства в пространстве, а является лишь соотношением высоты к ширине. Ещё проблема в том, что в альбомной ориентации высотой viewport'a является то значение, что было шириной в портретной ориентации. Этот может стать проблемой. Так, на IPhone X в альбомной ориентации срабатывают стили от портретной ориентации iPad 9.7" (768–1023px).
Коля Шоря, верить надо серверу, а точнее, его настройкам.
У вас сайт теперь весит 12 Мб. 124 запроса. Это пипец как много для подобного ресурса. Я не знаю, какие ещё у вас скрипты, как долго парсятся все эти фотографии на машине клиента, какой у вас сервер и т. д. У вас системные проблемы, которые нужно решать. Для начала советую продолжить поиск огромных фотографий и их уменьшение. Кроме того, нужно провести замену там, где нужно, PNG на JPG. Не все ресурсы нужно делать в PNG.
Ankhena, Сергей Горячев, да, точно, обязательно нужно выбрать Европу из списка, если сервер расположен в России. Тогда картина будет более реалистичной. Однако, стоит учитывать, что сервис грузит сайты по каналу с очень хорошей пропускной способностью, поэтому в реальности скорость загрузки на устройствах пользователей будет ниже.
Сергей Горячев, плохой сервер, плохая оптимизация в целом, много запросов, тяжелые скрипты, тяжелые для декодироания файлы в base64, неоптимизированный и тяжелый для рендеринга CSS, какие-нибудь неведомые JS-preloader'ы, лютые большие SVG, ещё что-нибудь -- причин миллион.
https://jsfiddle.net/w1pzu5rh/1/.
Зоны выделил разными цветами. Верстка на коленке, но алгоритм будет понятен. Под реальности проекта нужно, конечно, подстроить (ту же минимальную высоту поставить блоку, реальные размеры, верстку и т. п.).
NanoCSS пока ничего ни разу не сломал, что случилось, к примеру, с CleanCSS, но вполне возможно, что это мои косые руки.
Вообще, вы весьма интересную тему подняли.
Сейчас товарищ sim3x прислал ссылку (первую) на сводную таблицу результатов, есть повод задуматься. Надо тестировать.