ThunderCat

нарабоки класс, осталось мелочи:
0) проверить что это картинка
1) проверить что имя картинки уникальное, а то у сотен юзеров будет аватар untitled.jpg последнего загрузившего фото юзера (хинт: лучше не брать то которое дал юзер, а формировать свое гарантировано уникальное, например от логина пользователя)
2) Указать в запросе условие where, в котором привязать каритнку к конкретному пользователю, а не всем сразу

Скорее всего это должно подойти:

<picture>
   <source 
      media="(min-width: 650px)"
      srcset="images/img1.png">
   <source 
      media="(min-width: 465px)"
      srcset="images/img2.png">
   <img src="images/img-default.png" 
   alt="a cute kitten">
</picture>

Все сильно зависит. Да, на (не очень) старых машинках клиентсайд рендер сильно притормаживает, как пример - фликер, который практически весь сплошной json + js. Иногда ОООЧЕНЬ туго идет на сравнительно нестарых машинах. Гугль картинки емнип серверсайд и работают серьезно быстрее.

Обычно это не нужно, если это неотъемлемые свойства только статей, то не надо.

Ваши попытки напоминают операцию по удалению гланд через уретру, так как пациент отказался открыть рот. Вам абсолютно верно посоветовали СТАНДАРТНЫЕ методы работы с формой,
1) Заблокировать кнопку субмита или задать всему блоку pointer-events: none; user-select: none;, что отключит интерактивность формы.
2) После субмита, на стороне сервера делать редирект на какую-то страницу суксесс заказа, для предотвращения повторной отправки рефрешем.
3) Можно извратиться на стороне сервера и проверять был ли добавлен от этого клиента заказ в течение последних ЭН минут, но обычно после первых двух вариантов это не нужно.

зис.парентс(форм).файнд(нужный буттон).removeAttr("disabled","disabled");

во первых - скорость загрузки зависит от 3 параметров:
1) Скорость исполнения кода на сервере, которая в свою очередь делится на собственно код, и запросы к бд ( которые чаще всего и создают основную нагрузку и тормоза).
2) Скорость передачи данных и объем данных. Первое зависит от расположения сервера, удаленности от точки запроса, канала сервера и канала клиента. Второе, как вы понимаете, обычно зависит от качества и объема кода (html/js/json/картинки), передаваемых от сервера к клиенту.
3) Рендер страницы. Зависит от подключаемых скриптов / стилей, блокировок жс кода и объема и сложности разметки.

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

Для примерной оценки работы вашего сервиса я бы сравнил ваши показатели с примерно схожими крупными аналогами вашего сайта.

первый раз главная страница прогружалась около 40 секунд

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