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/.
Зоны выделил разными цветами. Верстка на коленке, но алгоритм будет понятен. Под реальности проекта нужно, конечно, подстроить (ту же минимальную высоту поставить блоку, реальные размеры, верстку и т. п.).
relows, это никакой не кринж, это абсолютно стандартное действие для подобных ситуаций, если вы хотите автоматическое выравнивание контента по границам, исходя из общей высоты.
alex-1917, наверное, у нас разные понимание «работающих» сайтов. Интернет-магазины (2 российских, 6 немецких), пара десятков лендингов (для США и Германии) — чем не рабочие сайты? И да, опять же, проверяю на реальных устройствах, ни разу не было проблем с производительностью. Даже у IE11 нет особых проблем (разве что с viewBox и трансформациями посредством CSS).
Возможно, вам просто лень делать векторные графические материалы :))
DeniSidorenko, да не за что, но это целая система, её нужно изучать. Мои знакомые, которые могут делать сайты подобного уровня на GSAP, получают по 10+ тысяч долларов в месяц :))
alex-1917, зачем такие иконки, размер которых строго 16 пикселей, а иначе они пойдут пиксельной кашей? А если у вас есть потребность сделать их хотя бы по 50 пикселей? Будете делать ещё один файл разрешением выше? А если нужно их анимировать? Поменять цвет иконки в соответствии с цветом текста?
Не совсем понял про подтверждение ваших слов, потому что все три пункта, которые я привёл выше, выступают против ваших аргументов. Когда, к примеру, с командой делали интерактивный лендинг-презентацию для Procter& Gamble, я не представляю, что бы было, если бы мы делали все графические элементы в растровых форматах. Никакой анимации, размытость элементов на экранах с высокой плотностью вкупе с нулевой экономией килобайт и т. п.
Ну или вот тут, на Toster.ru, когда открывается лайтбокс с картинкой, в правом верхнем углу висит пиксельная мыльная иконка крестика — не знаю, как вам, но мне это не очень нравится. Тем более в конце 2018-го года.
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-логика не особо сложная.
Но опять же скорость зависит от многих условий. Бывает и быстрее сборка, бывает медленнее.