ThunderCat

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

Я собирался сделать на JS вычисления рандома в диапазоне двух чисел, и при помощи if выводить результат о проигрыше, либо выигрыше.

Глупость кнечно, все что находится на строне клиента может (и будет) скомпрометировано и извращено.

Может быть вычисления на сервере?

Бинго!

Но как тогда подключить его к сайту, без возможности просмотра?

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

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

<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>

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

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

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

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

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

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

Ведь наверное не правильно будет сразу же слать запрос в бд

Правильно.

Вариантов несколько может быть
1) картинки тянутся с отличного от оригинала хоста (маловероятно, но вдруг, да и там обычно ошибка другая)
2) Картинки лежат в папке типа adv или что-то подозрительное для какого-то адблока (выключите плагины)
3) путь до картинок указан неверно

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

bootstrap / material / font awesome / free icon font / free web elements pack / themeforest.net / templatemonster.com

Столкнулся с отсутствием адекватной систематизации фреймворков для веб (не в каком-то отдельном языке)
...
У кого-нибудь есть идеи по систематизации этого добра? Критерии к выделению?

Фронтенд/бэкенд, остальное из перечисленного либо не относится чисто к веб (тесты это вообще больше QA, нежели разработка), либо ошибочно вами оценены как нечто не относящееся к этим двум разделам (например materialize - A modern responsive front-end framework based on Material Design).