dom1n1k

Без кода гадать сложно, поэтому просто версии наобум:
0. Внимательно проверить урл (иногда тупая ошибка сидит в каком-нибудь одном символе)
1. Попробовать указать cover отдельным свойством
2. Проверить doctype (не перешел ли IE в какой-нибудь режим совместимости?)

Да, обязательно и непременно.
В отличие от какого-нибудь PHP, где уже сложно представить себе сколько-нибудь серьезную разработку без фреймворка, верстальщик, который умеет только в Бутстрап - несомненный инвалид.

Я в таких случаях всегда делаю ссылку блочным элементом и вкладываю в нее картинку и надпись.
Да, я знаю, что это не совсем по спецификации (по стандарту в тэг [а] нельзя вкладывать блочные элементы), но это тот самый случай, когда имеет смысл наплевать на нытье о семантике и стандартизации :) Все работает и никогда с этим проблем не было. А плодить две ссылки - это и неудобно, и (по слухам) сеошниками не поощряется.

Вообще, конечно, проверять верстку в режиме 33% (на этой отметке у меня меню складывается в Хроме) как бы странно и бесполезно. Обычно люди увеличивают страницы. Уменьшать - ну ещё понимаю 70-90%, но точно не 33%.
Однако же этот как будто бы туповатый тест выявил проблемы в верстке. Я не смотрел всё, но пресловутое меню точно сверстано плохо и ненадежно. Его ширина никак не задана и ни от чего не зависит. По сути, блок nav просто распирается набором ссылок. Ещё там есть flex-контейнеры, но у дочерних элементов никак не заданы flex-basis, grow, shrink и вот это всё. Как это должно работать?
При каких-то условиях ссылки решили сложиться - ну и почему бы нет? Им верстальщик толком не заложил их поведение, браузер волен делать что хочет.

Типичный лендинг верстается 2-3 дня, как правило.
Хотя в принципе я вполне могу себе представить и такой, который неделю потребует.
Можно конечно и за день наговнокодить, как некоторые пишут, но я уверен, что найду там баги :)

DIN?

Бустрап да, в этом плане плох. Он вешает много стилей просто на тэги и на атрибуты, а не классы, поэтому они почти гарантированно конфликтуют с чем-то. Так что даже префикс не решает проблему на 100%.
Вообще, использовать бутстрап для виджета, который потом будет вставляться неизвестно куда - это явный моветон и говнокод.
Не помог, но выговорился.

Оно? https://habrahabr.ru/post/302744/

Фон отдельно от блока - никак.
Придется вынести его в отдельный блок, который как-то спозиционирован внутри родительского и там уже крутить.
А если угол наклона не нужно менять, то надо просто провернуть фон в графическом редакторе и сохранить как картинку.

https://css-tricks.com/snippets/sass/power-function/
И пусть поплачут те, кто пишет, что современному прикладному программисту математика не нужна :)

Соображение номер раз: параллельное расположение колонок хочется сохранить, потому что пользователь хочет не только прочитать тарифы, но и сравнивать их между собой.
Соображение номер два: 4 колонки это не так уж много, их в принципе можно утрамбовать в мобильный экран, особенно если использовать сокращения (мес, руб).

Я бы на мобильных устройствах левую колонку превратил бы межстрочные заголовки. Типа:

Вид аренды
Посуточно     Посуточно     Помесячно      Помесячно
Оплата агентских услуг
Ежемесячно    3 месяца      Ежемесячно     Единоразово

Реализовать, наверное, проще всего в лоб - продублировать эту информацию и прятать/показывать нужную копию.

Выделить критичный css-код и грузить его прежде всего. Возможен даже вариант со вставкой его инлайново в html.
А за прелоадеры хочется убивать. Пусть лучше моргает.

Подозреваю, что этот слайдер вообще не рассчитан на переключение ориентации на лету, а только при инициализации. Видимо, dom-деревья отличаются.

В большинстве случаев GF предпочтительнее почти по всем факторам кроме одного - утечки данных. Если вы не хотите, чтобы гугл собирал статистику по вам и посетителям - нужно к себе.

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

Не срабатывает потому, что :nth-child подразумевает сквозной номер элемента в родителе, а не среди подмножества элементов с каким-то классом.
Поведение это спорное и не всегда удобное, но так уж решили авторы спецификаций.