strelok011

скину ссылку на свой же ответ ранее https://qna.habr.com/q/1223280#answer_2254764

Оптимизация html и css по сравнению с оптимизацией png - бесполезная ерунда. Вы можете выиграть допустим 2-5 кб против 2-3 мб одного png, в условиях современного интернета этот выигрыш ничего не даст. Даже запрос на сервер может больше времени занять чем скачивание.
Необходимо обратиться именно к оптимизации png при этом желательно с минимальными потерями по качеству.
Советую для начала ознакомиться вот с этой статьёй How To Optimize PNG, а потом поискать инструмент поудобнее, просто погуглив PNG optimizer. Вот сравнение нескольких пакетных оптимизаторов. Я при необходимости оптимизации png использую RIOT, он может оптимизировать png, gif и jpg. Из личного опыта - советую попробовать первым делом оптимизацию палитры. Плюс есть не искажающие оптимизации (например, удаление мета-данных). Если используете прозрачность - она сильно добавляет веса в изображение, с ней тоже можно бороться.

Всё это хорошо, если у вас есть возможность оптимизировать изображения, статично размещенные на сайте.

Любая динамика с данными в окне браузера - нужен js. Работа в асинхронном режиме - таки да, это AJAX. Только сам термин ничего не объясняет.

Писать можно хоть на нативном js, можно подключать фреймворки типа jQuery, Vue, React и проч.
Вам придется хранить состояние формы (значения полей, ответы от бэкенда, служебные данные типа шага формы и др.), писать / использовать готовые модули для работы с календарем, отправлять запросы на эндпойнты бэкенда в асинхронном режиме, вешать крутилки (спиннеры) пока ожидается завершение запроса, перестраивать структуру документа чтоб отображать / скрывать шаги формы, писать валидацию заполнения данных, чтобы пользователь вводил только ожидаемые значения.
Готового "воткнул - работает" не найти, такие решения исключительно под конкретные требования пишутся.

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

попробуйте это

html {
  background-color: red;
  overflow: hidden;
  width: 100%;
}

body {
  height: 100%;
  position: fixed;
  /* prevent overscroll bounce*/
  background-color: lightgreen;
  overflow-y: scroll;
  -webkit-overflow-scrolling: touch;
  /* iOS velocity scrolling */
}

Ну, хотя бы потому что добавляя класс "modal open" вы добавляете отступ на оборачивающий блок справа padding 8 px. Соответственно написанным вами стилям контент смещается и на него влияют оборачивающие стили, а вот блок тулбара у вас position fixed, эта конструкция вырывает элемент из потока и отступ всей обертки на него не влияет.

Где вы такой замшелый способ прибития футера к низу нашли? Делайте на флексах, контентной части флекс гроу 1, общему контейнеру с флексом минимальную высоту 100% и этого будет достаточно.

Я так понимаю, когда вы хотите отображать модалку и замораживаете скролл, у вас пропадает ширина скроллбара и картинка (если скролл был) начинает скакать. Так вот в случае, когда контента не достаточно на появление скролла, у вас ровно обратная ситуация возникает.
Почитайте про варианты блокирования скролла, возможно найдете более подходящее решение.

Не нужно ничего вычислять. Ее нужно просто запросить. Это свойство clientHeight

Создаете массив колонок, пробегаете по нему, собираете высоту, ищете первую минимальную, втыкаете туда блок статьи, повторяете пока не кончатся блоки для вставки.

Дополню немного куратора - ваше меню должно решать ВАШУ проблему.
Всякие образцы в интернете - могут решать а могут и не полностью. Работает ли адаптив для разных разрешений, поддерживается ли тач, сколько уровней вложенности, нужно ли скрывать скролл для длинных списков (и всё же меню - это именно список), нужно ли скрывать подменять десктопное меню на мобильное...
Когда составите список требований - тогда и только тогда нужно будет подбирать конкретную реализацию, либо опираясь на примеры пилить своё.
Халтура - она не универсальная :)

Нельзя использовать нестандартные шрифты. Только в виде растра.
1. внедрять нельзя
2. делать внешние ссылки на шрифт плохая идея, если письмо попадает в корпоративную почту, внутри изолированной сети доступа к внешнему хранилищу не будет, так же нужно учитывать, что корпоративные почтовые сервера могут с легкостью выкашивать всё подозрительное из писем, включая ссылки на внешние ресурсы. Так, к примеру, ведет себя gmail.
Гуглите "безопасные шрифты" для использования в рассылках

это вопрос 10-летия на js )
Я надеюсь, что клики по элементу массива и прочую мелочь вы написать сможете.

Берем массив, хотим изменить последовательность двух элементов
вариант со старым js

var b = list[y];
list[y] = list[x];
list[x] = b;

b - временная переменная

вариант на es6
к примеру массив arr = [1,2,3,4]
[arr[0], arr[1]] = [arr[1], arr[0]];
будет массив [2,1,3,4]
это destructuring assignment.

А так-то да, заказывайте на фрилансе :)

А еще она напоминает... комбобокс, список объединенный с инпутом, с автокомплитом и т.п.
Смотреть можно сюда, либо на различные вариации. Реализация обычно на js, требует некоторой прокачки скиллов

Можно тут посмотреть. Видео - не наш выбор

Аналитику в конец. Она не должна влиять на скорость подгрузки значимых элементов и блокировать страницу для пользователя.
SVG как раз лучше в начало, при этом можно поварьировать подход - ссылку на svg-спрайт, либо прямо инлайном запилить в html и вызывать в нужное место просто по id. Если у вас 10 ссылок на декоративные элементы - это плохой подход. На старых http серверах каждый запрос является высоконагруженной операцией для сервера.
Основной js - тоже в конец документа, в самый низ либо подключать асинхронно. Инициализация на документ онлоад.
Суть такого подхода - чем раньше пользователь увидит контент, тем спокойнее он будет и какой-нить гугл спидрейнч вам покажет влияние на первое отображение контента пользователю.
На истину не претендую, рекомендую всё же такой подход и проверку внесенных изменений у гугла.

В парадигме scss вся эта ерунда может реализоваться миксом на уровне scss, а не на уровне микс-классов. Не стоит упарываться по идеологии.
Если вам важна цель - не надо перегружать разметку такими мусорными классами.