Артем Кайбагоров

Взять верстку, сделать на ЦМС схожий дизайн, перенести товары

Уменьшите битрейт и разрешение видео.
Переместите метаданные в начало mp4 контейнера
Установите preload="metadata"
htmlbook.ru/html/video/preload

Чтобы пиксели в глаза не бросались наложите на видео сеточку из маленьких черных точек
https://jsfiddle.net/soumyabg/wefLyrhp/
css background dotted overlay

Вас не спасёт ни MODX, ни БЭМ, ни React'ы с Angular'ами. Если использование инструментов сборки вызывают сложности — не используйте. Целесообразность их использования приходит лишь с опытом понимания того, что вы реально можете автоматизировать, от «магии» толку мало.
Это я вам говорю, как адепт БЭМ-стека (ага, того самого, из Яндекса) и амбассадор MODX.

примерно так

$(document).keydown(function(e) {
   if( e.keyCode === 27 ) {
      //что-то делаем
   }
}

Если контент один и тот же - лучше делать редирект, тогда гугл не будет вас штрафовать за дубликаты страниц

Правильнее всего установить главное зеркало через host как написано тут https://yandex.ru/support/webmaster/yandex-indexin... редирект можно сделать если не принципиально что бы сайт работал по обоим адресам, в противном случае лучше пусть работают оба сайта, т.к. когда происходит редирект на неожиданный адрес пользователи могут напугаться что они оказались не там где хотели и уйти.

Ваша идея полезна с точки зрения получения практических навыков и опыта "почему так делать не стоит".
Непонятно как Вы хотите снизить стоимость VPS обеспечив при этом доступность сайта.
Полной отказоустойчивости пока нет.

Можно создать много A/AAAA записей для имени сайта в DNS.
Но у посетителей они будут перебираться по очереди. Соответственно часть посетителей могут уткнуться в нерабочий сервер.
Можно сделать какой-то автоматический процесс который сменит DNS запись на рабочий хост. Но DNS кеш у некоторых посетителей будет возвращать им старый IP независимо от настроек TTL на DNS сервере.

Можно взять бесплатный эккаунт на CDN например CloudFlare и настроить скрипт который будет дёргать API и переключать backend сервер. По сравнению с записью в DNS, время переключения снизится, но всёравно кто-то вечно следящий в интернете это должен делать. Тоесть нужна мониторящая виртуалка, а лучше несколько.
Но в случае двух рабочих серверов Вам необходимо добиться синхронизации базы и файлов на обоих хостингах.
А это как минимум трафик между обоими серверами.

Правильно бы поставить HA Proxy и балансировать трафик он сам разберётся что и куда. Или другие подобные кластерные решения. Но это уже выходит за рамки бюджета любой одиночной виртуалки.

Если речь идёт о чистом Apache+PHP+MySQL хостинге то можно найти бесплатный или дешёвый вариант шаред хостинга. Если шареда мало, возьмите VDS/VPS есть дешёвые варианты. Хотя не факт что надёжнее чем домашний сервер.

Может можно для одного доменного имени сделать несколько А записей?

Можно. Только оно у вас будет round-robin'ом клиентам отдаваться. То ваш домашний IP, то адрес хостера. В итоге половина клиентов пойдёт туда, половина -- сюда.

Схем реализации вашей задачи несколько. Самая простая -- править А-записи, в случае падения домашней версии сайта. Т. е. если комп/канал упал, то исправляете в DNS А-запись на IP VPS-ки.

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

Единого ответа на ваш вопрос нету.
Смотря какой сайт и требования. Если это работа с БД, пользователями и загрузкой файлов - это достаточно сложная история. Надо собирать всё это в свою подсеть (например при помощи впн), настраивать репликацию БД, синхронизацию файлов и делать roud-robin dns например. Но это всё скорее всего будеи работать медленно

Если это постоянная отдача статичного сайта (например, ваш личный блог с огромной посещалкой)
то арендуете VPS, ставите на него nginx и в нем настраиваете проксирование с кешированием пол часа на ваш домашний сервер. таким образом если ваш сервер ляжет, то до получаса будет отдаваться сайт из кеша

Еще вариант на впс полная копия сайта, базы. сайт раз в минуту синхронизируете rsync, БД slave репликация. отвалился домашний сервер - vps отдает из реплики всё (но вносить туда изменения уже не получится, это надо предусматривать в коде)

вариантов, короче, много

mike153: пробовал все варианты. Nextcloud - это форк Owncloud. По сути, одно и то же, хоть и NC считается более продвинутым и вообще вся опенсорсная тусовка туда ушла. Поэтому пишу о нём. Всё исключительно на правах IMHO. Плюсы:
- Самый главный - это работа с файлами именно в файловом варианте. То есть, если предположить, что "всё упало", вы можете подключить диск с рухнувшего сервера к любому линуксу и вытащить инфу из /var/www или где она там у вас храниться будет. Также можно подключать внешние хранилища, то есть, предположим, есть у вас на сервере папка с фильмами и музыкой - их можно просто подключить в NC.
- CardDAV, CalDAV из коробки.
Минусы:
- Тормозит всегда, рандомно, в любой момент времени. Независимо от того Apache или Nginx, MySQL или MariaDB, тормозит на любом софте.
- Интерфейс - УГ, ШГ

Теперь о Seafile. Плюсы:
- Турбореактивный просто. Работает очень быстро.
- Интерфейс очень приятный.
- Продвинутое версионирование.
- Умеет открывать docx, odt, xlsx и т.д. без дополнительного софта. Но без редактирования. Если нужно редактирование - нужен отдельный Document Server от Collabora или Onlyoffice.
- PRO-версия бесплатна для 3-х пользователей, но смысла особого нет, т.к. enterprise-фишки заключаются в 1. полнотекстовому поиску по документам с помощью elasticsearch, у которого просто чудовищное потребление ресурсов 2. двух-факторной авторизации 3. и что-то там ещё, не особо нужное дома
- Есть клиенты для всех основных платформ
- Устанавливать можно как вручную по мануалу на сайте, так и воспользовавшись установочным скриптом, который сам всё сделает.
Минусы:
- Файлы хранятся в собственном формате, как это правильно называется? - на уровне блоков, что ли. Доступ к инфе только через веб-интерфейс, WebDAV, ну и приложения для синхронизации. То есть, вся информация в Seafile на диске представляет просто кучу мала из папок и файлов, которые нельзя так просто взять и использовать - нужен ещё дамп базы данных. То есть, в случае проблем с системой, достать информацию будет затруднительно. Но выход есть - seaf-cli - это безгуёвый клиент для синхронизации. Смысл в том, что на сервере, на котором крутится Seafile, дополнительно можно установить seaf-cli, натравить его на директорию, и он в эту самую директорию будет складывать синхронизированную копию инфы основной базы Seafile, причём в виде нормальных файлов, которые можно расшаривать как угодно, бэкапить и т.д. Минус решения с seaf-cli в том, что нужно вдвое больше дискового пространства для хранения инфы.
- Ну и как следствие такой организации файлов - невозможность подключить внешние хранилища, в отличие от тёплого лампового Nextcloud.

В общем, лично я остановился на Seafile.