ThunderCat

Имеет ли смысл искать способы ускорять эти запросы

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

Понял как вывести данные с БД

И как? Не вижу кода который у вас что-то вообще запрашивает из бд. БТВ данные из бд приходят обычно в виде массива (есть нюансы, но в целом так).

Это называется бэкенд, или server side (серверная часть), которая включает в себя собственно сервер, соответствующее ПО (хостинг платформа), а так же программную часть (на любом популярном языке под веб, и именно ее собственно надо будет реализовать) и хранилище данных (обычно база данных). Есть еще файловое хранилище, но в контекст вашего вопроса оно не входит.

Копайте в сторону чтения доки к апи.

При обращении к строке как к массиву вы не получаете "буквы", вы получаете байты, которые, в немультибайтовой кодировке, можно принять как текстовые символы. Так как утф8 - мультибайтовая кодировка с переменной "длинной символа", такой фокус с ней не проходит, работайте со строками только как со строками и все будет нормально.

Какую CMS

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

ЗЫ: раньше было так: https://habr.com/ru/post/36692/

одно и тоже имя оставлять в папках, соответствующих каждому размеру?

Очевидно же что рано или поздно вы перезапишете какую-то фотку, так как такое имя уже будет загружено (типичный пример без имени(1).jpg). И да - для каждого размера своя папка. Кроме того, часто имена фоток бывают на русском языке, с пробелами, в разном регистре, что для веба не очень хорошо. Фото надо переименовывать. Есть 2-3 варианта, которые зависят от условий. Самый простой и очевидный, подходящий для одной фото на объект - имя будет соответствовать идентификатору объекта (товара в вашем случае). Если их больше одной - можно использовать
а) идентификатор + _микротайм после точки,
б) хеш микротайма / идентификатора + _микротайма после точки,
в) просто микротайм
г) любой другой алгоритм, гарантирующий высокую уникальность и совместимость с вебстандартами.

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

Для вывода изображений используйте <picture>, в котором задайте приоритеты вывода и размерность.

Все поля, которые используются в сравнениях, группировках и сортировках.

PWA?

Варианта 2:
1) Раздолбайство, и нормальным выходом будет типовое тз, простенькое, но с 90% описанного функционала через юзкейсы. Предложите, возможно даже зайдет.
2) Заказчик платит за валерьянку и время по общему тарифу, так что фирма в шоколаде полюбому.

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

TL;DR: переписывайте базу пока не поздно. Приводите в 3 нормальную форму и будет вам "щастие".

1) Хранение данных по которым идет поиск в таком виде - это сразу расписаться в своей проф. непригодности, никому не показывайте эту стыдобу.

2) Разнесите данные нормально по таблицам, не думайте что вы прям "выкрутились" захерачив все в строку и у вас все в шоколаде. Нифига, теперь у вас по этому полю будут кошмарно тормозные запросы, так как самые медленные операции - это лайк и регексп. Тем более по полю с переменной длинной и без нормальных индексов. И все это вместо суперскоростного индекса по интежер полю.

3) Кроме остальных проблем - теперь вместо просто апдейта поля вам сначала надо его считать, распарсить и только потом обновлять, чтобы не потерять информацию, то есть вы часть стандартной логики бд переносите в код, где ему не место.

4) ну и на одну из проблем вы уже напоролись - поиск по нечетким данным даст нечеткий результат.

Необходимо узнать сколько было показов иллюстрации и сколько было переходов на страницу с иллюстрацией.

На техническое описание не похоже... Считайте просмотры страниц с иллюстрациями, все остальное бред и статистический мусор, вы скорее потонете в его объеме, нежели что-то толковое для себя выведете. Если просмотры это увеличение изображения по клику и вам их надо прям вот посчитать - тупо аяксом при клике отсылаете айди иллюстрации на какой-то свой счетчикКонтроллер и зачитывайте "интерес"... А так - фокус, прокрутка- это все пальцем в лужу...

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

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

попробовав пописать на ларавел я понял, что он даётся ощутимо тяжелее чем чистый PHP.

Это по тому что у вас нет понимания ооп в достаточном объеме. Да и "чистый" пхп нифига не проще, если писать что-то чуть сложнее чем "несложный сайтик на классах", и вы быстро потонете в говнокоде.

Ларавел, как впрочем и другие фреймворки, дает уже готовую структуру, + кучу готового функционала, в том числе и структурированную основу, где у вас основной задачей становится именно дописать немного кастомного функционала, не покрытого внутренними механизмами движка, или отсутствует готовая библиотека под нужную фичу. Далее все сводится к манипуляции готовыми объектами. Что касается выбора - новичку скорее зайдет Лара, так как симфони на порядок сложнее по использованию искаропки, в Ларе же много чего просто уже работает, причем визуально гораздо проще чем в симфони, хотя за фасадами там достаточно такой сложный для новичков код, но обычно туда и не лезут без особой необходимости.

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