Что нужно сделать, чтобы веб приложение работало максимально быстро?

пробовал на расте оптимизировать скрипты для хайлоада своего в 10к rps...
для веба не актуально,
разница на вычислениях в ~2мс, когда ответ вебсервера на порядок больше ~10-20мс,
а рнр сейчас довольно шустро работает, особенно с JIT
узкие места это бд и вебсервер

Да, вообще изначально сервер подобрать и потестировать.

Узкие места это всё: от хостера, до запросов. Оптимизация запросов, поисковые индексы, количество каналов провайдера у хостера, асинхронные запросы и прочее, прочее. 

Если исходить из того, что WEB-приложение – это в большинстве случаев PHP+MySQL (первое – язык программирования, второе – базы данных), то...

Поехали.

В 99% случаев причина «тормозов» – кривой алгоритм. Приведу свой любимый пример, который понятен практически всем. Есть группа из 10 строителей, из этой группы нужно взять 5 строителей и отвезти в соседний город, чтобы занялись там строительством, остальные пятеро нам не нужны. Логично сделать как? Сразу отбираем из группы одного за другим нужных нам пятерых, сажаем их всех в автобус и поехали на локацию. По пути спросим у них что? – номер телефона, имя, на крайняк возраст. Остальное нам не нужно, работа простая – кирпичи укладывать. Понадобится что вдогонку – спросим у них, чай не немые.

Теперь о том, как работают современные движки (Битрикс, WordPress и пр.): они выбирают из группы одного строителя и заполняют на него досье (вообще всё, на всякий случай – дата рождения, возраст, пол, вероисповедание, список хобби и пр.) Затем отвозят его в соседний город, на объект, укладывать кирпичи. Возвращаются обратно за следующим строителем. Проделывают всё то же самое, что и с первым, и точно так же везут его в соседний город. Нужны 5 строителей – а стало быть, будет 5 таких итераций. По рейсу на каждого строителя. Зато универсальность методов. Зато если что понадобится – всё под рукой.

Так вот, первый подход называется агрегатным и работает быстро, но используется редко, так как должен быть заточен под конкретный набор данных. А второй попроще и значительно медленнее, зато используется практически везде, ибо универсален и работает по принципу «отдельный квант информации, независимы от других квантов».

Ещё можно было бы, конечно, упомянуть инфоблоки Битрикса с рекурсивным многослойным извлечением и расшифровкой сериализованных данных из одноранговой таблицы, но это отдельная тема и на ночь глядя о таком не нужно, а то будут сниться плохие сны. Как это вообще сдвигается с места и умудряется шевелиться на виртуальном хостинге у магазинов с ассортиментом более 1000 наименований – для меня до сих пор загадка. А прикиньте между делом, ведь мне встречались случаи, когда на Битриксе лендинги делали!

То же самое с базами данных, там тоже можно наворотить такое, что даже записная книжка на 50 телефонных номеров начнёт тормозить. Не говоря уж о банальном отсутствии правильных индексов таблиц. Ещё в базы данных любят запихивать картинки в двоичном формате, это отдельная тема для разговора. 

Теперь главное. Современные движки универсальны, они сразу обвешаны всеми модулями на всякий случай, вплоть до оплаты межпланетных рейсов через PayPal с банковской карты через Webmoney перечислением наличных на деревянные бухгалтерские счёты. Поэтому крупные проекты пишутся только вручную, а всё нужное подключается по мере необходимости.

Вот и весь секрет быстроты.

А вы крутой программист! Выбираем нужных  строителей по "идентификатору", а уже в пути запрашиваем свойства объекта - фио, телефон, пол и т.п.  ООП это не кривой алгоритм.

Большинство виджетов подгружаются на сайты в асинхронном режиме, основной же контент страницы поставляется базовым программным ядром. В этом легко убедиться, открыв в браузере панель вебмастера: «водопад событий» сразу же покажет, что сколько загружается. В 80% случаев медленно работает именно ядро (5-15 секунд), а всё остальное подгружается ещё несколько минут. Средний результат загрузки контента страницы сайта в 3 секунды на сегодня считается фантастическим. А при упоминании мной трёх-пяти десятых секунды на загрузку контента – со мной попросту перестают разговаривать, так как люди не любят общаться с отъявленными лжецами, за одного из которых меня принимают. А ведь 0,5 секунды при формировании страницы в PHP 7, даже включая рендеринг страницы браузером – это, на мой взгляд, чересчур многовато.

На проектах где высокий RPS (конечно если позволяет ситуация) вполне резонно в узких местах уходить от "типового поведения". Не скажу зв ВП, но в Битриксе это вполне нормально реализуемо. (у меня есть проект где бываю моменты когда приходит более 150К пользователей активных, при чем не размазано на все сутки, а именно норовят все разом). Ну, а далее все так: и алгоритмы и структура БД (Включая денормализацию), кеширование и т.д и т.п.

Инфоблоки прекрасно работают на 1000 :) и даже значительно больше. Т.е. при грамотном кешировании это не особо проблема. Например (из проектов на моем обслуживании) каталог порядка 150к товаров и примерно столько же торговых предложений, нормально работает, хотелось бы быстрее, но проблема скорее в шаблоне и его универсальности (в дополнение к самому битриксу). Второй пример (где напрягает уже именно кухня Битрикс - там чуть меньше товаров, но вот свойств несколько тысяч - исторически так сложилось. Но там ускорили переводом фронта на node.js.

Как итог, конечно же при необходимости "ускорения" урезать "универсальность" вполне себе путь и, полагаю, для любого проекта (где есть универсальность). Но опять же у каждого проекта свои возможности и варианты. Где то надо часть таблиц в отдельную БД вытащить, где то часть функционала вырезать в отдельный сервис и т.д. и т.п. 

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