Алексей Струков

Бери одну картинку, размером "требуемая максимальная ширина экрана помноженная на два" и делай ее. Это самый простой вариант. Если хочется немного пооптимизировать, то бери две картинки - одна большая как в первом случае, а вторая - в два раза меньше. Оптимизировать отдельно для каждого устройства не обязательно - на скорость загрузки это особо не влияет. Картинки только не забудь сжать оптимизатором)

Судя по всему, ты хочешь первый экран сделать с большой картинкой на всю ширину. Тогда ставь ее через background-image и медиа-запросы. В общем все)

Сафари теперь не позволяет отключать зум, однако строка user-scalable=no в meta по прежнему полезна для запрета зума при нажатии на input

Называть классы лучше так, чтобы по названию можно было понять что он делает. Длинные имена в общем не проблема. можно попробовать использовать BEM-подход или взять оттуда некоторые принципы и написать собственную методологию. Например у меня все классы делятся на несколько категорий:

row (горизонтальный блок на сайте)
col (делит row на несколько секций)
wrap (оборачивает компонент, который находится внутри col)
item (сам компонент)
text (текст, который находится внутри компонента)

У каждой категории классов есть свой набор свойст которые к нему применяются. Например сетка работает с col-классами и следовательно, когда я вижу класс типа .col-width-50-s, то я знаю что тут структурный стиль для сетки, в котором присваивается ширина 50 процентов на мобилах. А класс item-table_caption это заголовок компонента-таблицы.
Когда в голове создашь свою иерархию классов, то проблем с названием селекторов не будет и их очень легко читать/писать станет.

У такого подхода есть как плюсы, так и минусы.
Плюс - вы берете самые интересные решения из разных методологий и создаете инструмент под себя (мне нравится атомарный подход, mcss и bem, но у всех них есть свои недостатки)
Минус - другие разработчики не всегда могут читать ваш код также легко как и вы. Однако, как показывает практика, методологии приходят и уходят и возможно изобретенный вами подход станет новым стандартом в будущем)

Такое лучше на svg делать.
Сложные фигуры на css это баловство. Если заказчик хочет такую сложную штуку, то завтра он может попросить сделать ее еще сложнее (по закону Мерфи обычно так и бывает) и один хрен придется делать потом на svg. Так зачем тратить время на css-костыль и оттягивать неминуемое?)

Поставь этим инпутам type=text и например pattern=[0-9]+ (надо тестировать и подбирать паттерн под свои нужды)
Чтобы форма точно не проходила, надо использовать валидацию через js.
Встроенная html5 валидация работает не везде одинаково, а на айфоне вообще не обращает внимание на атрибуты required и отправляет пустые поля на сервер.

User-scalable=no перестал поддерживаться в ios10(и возможно на некоторых других платформах). Признан плохой практикой.

Ретина только на картинки влияет, делая их размыленными. Самый простой способ - бери все изображения с увеличенным в 2 раза размером.
Например нужна картинка 100 на 100 пикселей на сайте - бери картинку 200 на 200 и указывай ей размер в css 100x100.
Таким образом ты заставишь ретина-дисплей отображать картинку с двойной плотностью пикселей.

Есть еще экраны с х3 или х4 плотностью, но я не замечал стлной разницы в качестве изображений на них, так что можно забить.

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

Делаешь три колонки:

В первой колонке создаешь два ряда. Во втором из этих рядов делаешь еще две колонки.

Во второй колонке делаешь два ряда.

В третьей колонке делаешь тоже самое что и в первой.

По html пробежался:

У тебя есть места где тег h2, h3 идет перед h1. Так делать не принято (хоть и не считается ошибкой при валидации). Почитай про html document outline - это система структурирования документа по заголовкам и секциям.

Встречаются пустые конструкции из дивов, которые видимо используются в презентационных целях и захламляют документ (лучше использовать псевдоэлементы before и after для этого)

Презентационные картинки типа иконок не нуждаются в заполнении аттрибута alt (оставить его пустым лучше, но не убирай) и можно добавить role=presentation. Картинки не адаптированы под ретину (почитай про аттрибут srcset).

Input'ам, без описательного тега label, не нужен аттрибут title (он не на всех скринридерах работает и на мобилах он не отображается) Если решили уж делать поле ввода без label, то пусть лучше аттрибут placeholder описывает максимально, что требуется от простого пользователя, а для пользователей скринридеров использовать aria-label.

Последний момент: если хочешь прям ваще чтоб идеально было, то надо внедрять в код wai-aria, но спешу тебя обрадовать, что об этом любят только говорить всякие гуру на конференциях, а на деле практически никто это не внедряет правильно, так как требуется в WCAG и Section508

Ну в остальном все нормально в общем, кроме всяких вещей субьективных типа структуры вложенности дивов. Я лично не люблю когда их очень много, но некоторым так удобней держать в голове структуру документа. Сам сайт не сравнивал с кодом, поэтому мог не заметить каких то еще явных косяков - пробежался просто поверхностно глазами по html на гитхабе.