В нескольких больших проектах, в которых я участвовал, одним из первых разработанных компонентов интерфейса был «лоадер». Ну такая обычно круглая крутилка на весь экран, пока данные не загрузятся. Часто его делали отдельным слоем, затемняя или размазывая всё под лоадером.

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

Первое, что мы сделали — избавились от лоадера на всю страницу. Если какие-то части и не могут быть подгружены сразу, то нужно показывать лоадер на их месте, а не перекрывать всю страницу.

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

Долгое время у нас всё получалось, страницы загружались быстро. Для этого мы сделали что-то такое:

• Сделали индексы в БД
• Запрашивали столько информации, сколько нужно отобразить сразу
• Кешировали запросы

Со временем, когда документов и таблиц стало очень много, мы всё таки вернулись к лоадеру, только системному. Мы меняли курсор мыши на курсор с загрузкой, если загрузка идёт больше половины секунды. Это решение хорошо тем, что для него не нужно что-то серьёзное программировать отдельно, что оно будет естественным образом работать на любом ПК (мы разрабатывали только дескопные версии продуктов), но оно всё равно говорит только о том, что мы недостаточно хорошо решили задачу.

К примеру, можно было бы:

• Разделить данные в БД на актуальные и нет и хранить их в разных таблицах
• Хранить копию БД в оперативной памяти и получать данные из неё
• Осуществлять кеширование на уровне NGINX, не обращаясь к бекэнду и к БД
• Хранить редкоменяющиеся данные в хранилище браузера

и наверняка ещё множество манипуляций, которые хорошо известны ребятам из ВК или Ютьюба, у которых есть по-настоящему много данных и много пользователей

Программисты знают, что есть как бы настоящие языки программирования C++, Go, программы на которых компилируются и выполняются очень быстро, и ненастоящие Python, PHP, JavaScript, программы на которых интерпретируются и выполняются медленно. Ну ещё особняком стоит Java, которая вроде и интерпретируемая, но и не совсем.

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

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

Подробнее об этом в статье «Когда не хочется переделывать».

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