Николай Шаяхметов

Надо разделить приложение на фронт и бэк в таком случае.

React, vue, angular, svelte делят приложение на компоненты. Вся страница это один большой компонент (внутри него маленькие) и для переключения этих компонентов используются route библиотеки. Они даже меняют url в адресной строке, но по факту сервер отдаёт один и тот же html, js, css, а какой компонент отобразить решает route библиотека уже на клиенте. Можно рендерить js на сервере с помощью next.js, но это другая история.

PHP здесь уже в связке с каким нибудь symphony отдаёт ТОЛЬКО объекты JSON. Позволяет создать объект, удалить, изменить, получить и прочая логика. Бэк связан с базой данных. Обычно для удобства к нему кидают Swagger или OpenAPI. Я здесь описываю REST API. Можешь реализовать gRPC или GraphQL

Чтобы с бэка получить данные на фронт юзают такие библиотеки как redux (для react), так называемые state менеджеры. Бэк ничего не знает о фронте! Вместо react приложения работающего в браузере можно мобильное или нативное приложение разработать без изменений в бэкенде.

А деплоиться это всё может так:

Берёшь веб-серевр (apache2 как пример). Настраиваешь reverse-proxy. Он обслуживает порт 80 или 443. Задача его перенаправлять запросы, например в docker контейнер, где у тебя задеплоен PHP на порт 3001 например, которые начинаются с domain.com/api. Всё остальное летит на другой docker контейнер с ip 3002 где у тебя задеплоен фронт. Можно конечно ещё запариться. Так как фронт у нас это html, js и css + картинки и это статика, то его можно на CDN закинуть и получать за мгновение из любой точки мира. А бэк это "лёгкий" (в сравнении с фронтом) JSON.

Заметь фронт и бэк разные сущности. Фронт знает о бэке, а бэк о фронте нет.

Так что отдавать react через php ненужно

Junior разработчиком после выполнения пары проектов в отвратительном качестве не стать.

в моей голове junior - это тот, кто пишет круды и что-то там допиливает в проектах

Этот тот которому дают простое задание и говорят, как делать и он делает, так как ему сказали.

Я могу сделать какой-нибудь обычный crud с sql, но, видимо этого не достаточно.

У Вас не обычный CRUD, а тот который никогда делать не надо. Следует узнать о шаблозаторах Twig и Smarty. Попробовать сделать свою простую шаблонизацию на PHP, что бы отделять верстку о логики.

Также у меня есть пару книг популярных по этому языку и там тоже нечего взять полезного.

Я думаю, если бы Вы прочитали PHP 7 Котерова, может быть не задавали бы такого вопроса. Можете начать с PHP 7, и обязательно выполнять задания, которые там даны в конце каждой главы. Если хочется быстрее понять PHP можете пройти интенсив. (бонус, что будет опытный наставник и работа с системой контроля версий).

После того, как будет понимание о языке PHP и его возможностях, следует посмотреть на работу с SQL, создать несколько баз данных руками, попробовать JOIN из нескольких таблиц, написать простой CRUD каталог по архитектуре MVС, что бы понять, как реализуется роутинг.

Поиграться с каким нибудь API, делать получение и отправку запросов.

Изучать тему Linux и как работать в консоли, настройка LAMP и LEMP окружения.

Желательно посмотреть на Docker и Vagrant, запустить их у себя на машине и установить внутри какой нибудь обычный WordPress.

Попробовать работу с PHP фреймворками, сделать несколько простых проектов.

Изучать лучшие практики работы PHP правильный путь

P.S. и постоянно учиться чему то новому...

Предложу свой вариант (для точности переключения нужно поиграть со значениями top и bottom)
jsfiddle.net/bonilka/p7sgwg4L

Разница понятий веб сайта и веб приложения заключается не в том какой паттерн применяется при разработке, главным образом основное различие заключается в доставке контента пользователю, под сайтом мы подразумеваем веб-сервер к которому пользователь обращается по определенной ссылке и получает страницу согласно настройкам роутинга веб-сервера.
В случае же с веб приложением, пользователь при переходе на любую из ссылок веб-сервера обращается в изначальную точку входа ( как правило index.html ), и после происходит скачивание js скрипта, который в дальнейшем управляет веб приложением ( переходы по ссылкам, отображение информации, роутинг )

Говоря о стандартах, нет каких то явных стандартов построения приложении/сайтов все архитектурные решения производятся на этапе проектирования продукта, после выявления потребностей заказчика, стека технологий.

\common\config\bootstrap.php
добавить:

Yii::setAlias('@folder', dirname(dirname(__DIR__)) . '/folder');

мне этого оказалось достаточно для добавления папки в корень проекта

По пунктам:
1. Используйте современные форматы изображений - гугл хочет чтобы на сайте использовались более легкие(не всегда, но в большинстве случаев) варианты изображений в формате допустим .webp
2. Настройте эффективную кодировку изображений - значит что изображения слишком много весят
4. И самое главное, что влияет на все предыдущие пункты - некорректное соотношение размера отображаемого изображения - его визуальному размеру. К примеру - у вас изображение 2500px, действительно ли его нужно отображать на смартфонах в полный размер. или достаточно превью?

<article>
  <img srcset="https://dummyimage.com/2560x400/333/fff 2x,
               https://dummyimage.com/1280x400/333/fff 1x"
       sizes="(min-width: 1280px) 1280px, 100vw"
       alt="A title">
</article>

По вышеописанному коду для современных мобильных используется srcset=https://dummyimage.com/2560x400/333/fffтак как у них плотность пикселей 2x. PageSpeedInsights эмулирует отображение на аналогичном смартфоне.
Для более гибкого подхода в html5 появился элемент picture. Подробнее посмотреть советую у Вадима Макеева в этом же видео подробно разбирается оптимизация графики для сайта.
На примере вашего кода можно сделать набросок

<picture>
    <!-- source для браузеров поддерживающих webp, соответственно srcset тоже должен указывать на webp-->
    <source type="image/webp" srcset="https://dummyimage.com/575x150/333/fff 1x, https://dummyimage.com/1150x300/333/fff 2x," media="(max-width: 575px)">
     <!-- source для браузеров не поддерживающих webp -->
     <source srcset="https://dummyimage.com/575x150/333/fff 1x, https://dummyimage.com/1150x300/333/fff 2x," media="(max-width: 575px)">
    ...  <!-- все остальные необходимые размеры, вроде планшетов и т.д. -->
    <!-- fallback для браузеров не поддерживающих элемент picture -->
    <img src="https://dummyimage.com/2560x400/333/fff" alt="A title">
</picture