История изменений

Статику и реверс-проксирование можно делать чем угодно, но разумно это делать nginx-ом, ничего принципиально лучше пока нет.

Стоит внимательно проанализировать протокол HTTP. Выбрать правильную версию (сегодня это HTTP/3), включить сжатие ассетов с правильным алгоритмом (brotli), возможно стоит сжать ассеты заранее. Кеширование статики должно работать нормально.

Для дальнейшего ускорения отдачи статики нужно использовать CDN. Если у тебя магазин обслуживает один регион, это излишне, просто убедись, что твой сервер расположен в том же регионе. Если хочешь работать на всю Россию, можно подумать о CDN, чтобы статика отдавалась с сервера поближе к пользователю, скорость света - противная штука.

С динамикой всё работает примерно одинаково. Если хочешь максимальную производительность разумными усилиями - Go. Хуже всех по моему опыту Python. Но это экономия на спичках, с большой вероятностью любой популярный вариант будет работать достаточно быстро. Если что-то будет тормозить, то обычно это проблема плохо написанного кода.

База любая из популярных подойдёт, опять же если что-то будет тормозить, то это проблема плохо написанных запросов в базу.

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

Фронтэнд можно любой, опять же все проблемы с производительностью будут следствием плохого кода, а не неправильного выбора фреймворка. У JS-экосистемы есть проблема разрастающихся зависимостей, на клиенте это может стать проблемой, поэтому очень тщательно относись к выбору используемых библиотек. Чаще всего лучше написать свой велосипед из сотни строк, чем подключать библиотеку, которая подтянет ещё пару сотен зависимостей (не сегодня, так завтра). HTML/CSS лучше писать самому, а не использовать популярные библиотеки со стилями.

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

Добавлю, что стоит внимательно относиться к выбору серверов. Серверы бывают разные, и производительность у них разительно отличается. Также хостеры могут либо резервировать для тебя процессорные ресурсы, либо делить их с другими клиентами. Во втором случае никакой предсказуемости не будет. В целом лучше пользоваться «взрослыми» облаками, там всё сделано по-уму, даже если это просто виртуальная машина.

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

Статику и реверс-проксирование можно делать чем угодно, но разумно это делать nginx-ом, ничего принципиально лучше пока нет.

Стоит внимательно проанализировать протокол HTTP. Выбрать правильную версию (сегодня это HTTP/3), включить сжатие ассетов с правильным алгоритмом (brotli), возможно стоит сжать ассеты заранее. Кеширование статики должно работать нормально.

Для дальнейшего ускорения отдачи статики нужно использовать CDN, но для небольшого магазина это излишне.

С динамикой всё работает примерно одинаково. Если хочешь максимальную производительность разумными усилиями - Go. Хуже всех по моему опыту Python. Но это экономия на спичках, с большой вероятностью любой популярный вариант будет работать достаточно быстро. Если что-то будет тормозить, то обычно это проблема плохо написанного кода.

База любая из популярных подойдёт, опять же если что-то будет тормозить, то это проблема плохо написанных запросов в базу.

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

Фронтэнд можно любой, опять же все проблемы с производительностью будут следствием плохого кода, а не неправильного выбора фреймворка. У JS-экосистемы есть проблема разрастающихся зависимостей, на клиенте это может стать проблемой, поэтому очень тщательно относись к выбору используемых библиотек. Чаще всего лучше написать свой велосипед из сотни строк, чем подключать библиотеку, которая подтянет ещё пару сотен зависимостей (не сегодня, так завтра). HTML/CSS лучше писать самому, а не использовать популярные библиотеки со стилями.

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

Добавлю, что стоит внимательно относиться к выбору серверов. Серверы бывают разные, и производительность у них разительно отличается. Также хостеры могут либо резервировать для тебя процессорные ресурсы, либо делить их с другими клиентами. Во втором случае никакой предсказуемости не будет. В целом лучше пользоваться «взрослыми» облаками, там всё сделано по-уму, даже если это просто виртуальная машина.

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

Статику и реверс-проксирование можно делать чем угодно, но разумно это делать nginx-ом, ничего принципиально лучше пока нет.

Стоит внимательно проанализировать протокол HTTP. Выбрать правильную версию (сегодня это HTTP/3), включить сжатие ассетов с правильным алгоритмом (brotli), возможно стоит сжать ассеты заранее.

Для дальнейшего ускорения отдачи статики нужно использовать CDN, но для небольшого магазина это излишне.

С динамикой всё работает примерно одинаково. Если хочешь максимальную производительность разумными усилиями - Go. Хуже всех по моему опыту Python. Но это экономия на спичках, с большой вероятностью любой популярный вариант будет работать достаточно быстро. Если что-то будет тормозить, то обычно это проблема плохо написанного кода.

База любая из популярных подойдёт, опять же если что-то будет тормозить, то это проблема плохо написанных запросов в базу.

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

Фронтэнд можно любой, опять же все проблемы с производительностью будут следствием плохого кода, а не неправильного выбора фреймворка. У JS-экосистемы есть проблема разрастающихся зависимостей, на клиенте это может стать проблемой, поэтому очень тщательно относись к выбору используемых библиотек. Чаще всего лучше написать свой велосипед из сотни строк, чем подключать библиотеку, которая подтянет ещё пару сотен зависимостей (не сегодня, так завтра). HTML/CSS лучше писать самому, а не использовать популярные библиотеки со стилями.

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

Добавлю, что стоит внимательно относиться к выбору серверов. Серверы бывают разные, и производительность у них разительно отличается. Также хостеры могут либо резервировать для тебя процессорные ресурсы, либо делить их с другими клиентами. Во втором случае никакой предсказуемости не будет. В целом лучше пользоваться «взрослыми» облаками, там всё сделано по-уму, даже если это просто виртуальная машина.

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

Статику и реверс-проксирование можно делать чем угодно, но разумно это делать nginx-ом, ничего принципиально лучше пока нет.

Стоит внимательно проанализировать протокол HTTP. Выбрать правильную версию (сегодня это HTTP/3), включить сжатие ассетов с правильным алгоритмом (brotli), возможно стоит сжать ассеты заранее.

Для дальнейшего ускорения отдачи статики нужно использовать CDN, но для небольшого магазина это излишне.

С динамикой всё работает примерно одинаково. Если хочешь максимальную производительность разумными усилиями - Go. Хуже всех по моему опыту Python. Но это экономия на спичках, с большой вероятностью любой популярный вариант будет работать достаточно быстро. Если что-то будет тормозить, то обычно это проблема плохо написанного кода.

База любая из популярных подойдёт, опять же если что-то будет тормозить, то это проблема плохо написанных запросов в базу.

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

Фронтэнд можно любой, опять же все проблемы с производительностью будут следствием плохого кода, а не неправильного выбора фреймворка. У JS-экосистемы есть проблема разрастающихся зависимостей, на клиенте это может стать проблемой, поэтому очень тщательно относись к выбору используемых библиотек. Чаще всего лучше написать свой велосипед из сотни строк, чем подключать библиотеку, которая подтянет ещё пару сотен зависимостей (не сегодня, так завтра).

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

Добавлю, что стоит внимательно относиться к выбору серверов. Серверы бывают разные, и производительность у них разительно отличается. Также хостеры могут либо резервировать для тебя процессорные ресурсы, либо делить их с другими клиентами. Во втором случае никакой предсказуемости не будет. В целом лучше пользоваться «взрослыми» облаками, там всё сделано по-уму, даже если это просто виртуальная машина.

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