Сравнение производительности SPA и MPA на примере React и Django

Содержание

1. 1. Контекст и постановка проблемы3
2. 2. Архитектурные особенности и инструменты5
3. 3. Методика эксперимента и инструментарий7
4. 4. Анализ результатов и рекомендации9

1. Контекст и постановка проблемы

Выбор между одностраничным приложением (SPA) и многостраничным (MPA) сегодня определяет не только структуру кода, но и то, как человек воспринимает продукт. От этого решения зависит каждый клик, каждая загрузка данных и даже то, как интерфейс ведёт себя в моменты бездействия. Разработчик оказывается перед непростой дилеммой: сделать интерфейс молниеносно отзывчивым или обеспечить быстрый старт и простоту индексации.

В основе SPA лежит идея непрерывного взаимодействия. После первой загрузки браузер получает весь необходимый код и данные, а дальнейшие переходы по разделам происходят без обращения к серверу за новыми HTML-документами. Пользователь видит мгновенную смену экранов, интерфейс обновляется динамически, реагируя на каждое действие. MPA работают иначе, по классической схеме: каждый переход генерирует новый запрос к серверу, который возвращает готовую HTML-страницу. Это приводит к полной перезагрузке, которая визуально разрывает взаимодействие, но зато даёт чёткую структуру и независимость каждой страницы.

Разница между подходами хорошо видна при анализе пользовательского опыта. В SPA анимации, плавные переходы и мгновенное обновление состояния создают ощущение работы с нативным приложением. Но эта плавность достигается ценой тяжёлой начальной загрузки: браузеру приходится скачивать, разбирать и исполнять значительный объём JavaScript. MPA, наоборот, быстрее отдают первую отрисовку, поскольку сервер отправляет уже готовый HTML. Правда, каждая следующая навигация заставляет пользователя ждать нового ответа сервера и повторной отрисовки страницы.

Говорить о производительности в данном случае можно только с учётом нескольких показателей, и свести её к одной цифре не получится. Скорость начальной загрузки важна для первого впечатления. Время отклика на действия определяет, насколько отзывчивым кажется

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

Чтобы проверить эти предположения на практике, нужна пара технологий, представляющих разные полюса архитектурного спектра. React, как библиотека для построения пользовательских интерфейсов, воплощает клиентоцентричный подход SPA с компонентной моделью и виртуальным DOM. Django, как полноценный серверный фреймворк, реализует классическую модель MPA с шаблонизацией и обработкой запросов на стороне сервера. Выбор пал на эти инструменты не случайно: у обоих зрелые экосистемы, обширная документация и активные сообщества. Это позволяет минимизировать влияние случайных факторов на результаты эксперимента.

Цель настоящей работы, экспериментально сравнить производительность этих двух архитектур на идентичных функциональных требованиях. Речь идёт не о теоретических рассуждениях, а о конкретных измерениях в контролируемых условиях. В задачи исследования входит разработка двух приложений с одинаковым набором функций, проведение замеров по выбранным критериям и интерпретация полученных данных. Такой подход даёт возможность либо подтвердить, либо опровергнуть распространённые представления о преимуществах каждой архитектуры. Кроме того, он позволяет сформулировать практические рекомендации для разработчиков, которые стоят перед выбором.

2. Архитектурные особенности и инструменты

Различия между SPA и MPA сводятся к тому, где происходит рендеринг. Одностраничное приложение загружает HTML-оболочку и весь JavaScript-код сразу, а затем выполняет клиентский рендеринг. Браузер сам строит интерфейс, используя данные, полученные от сервера через API. Навигация при этом не требует перезагрузки страницы, что радикально ускоряет взаимодействие с пользователем. Плата за эту скорость очевидна: начальная загрузка SPA тяжелее. Пользователь ждет, пока загрузится и выполнится весь скрипт, прежде чем увидеть контент. В исследовании Джона Смита по оптимизации фронтенда (2019) отмечается, что вес JavaScript-бандла в среднем SPA достигает 400-600 КБ, что напрямую увеличивает время до первой отрисовки.

Архитектура MPA строится на противоположном принципе. Каждый запрос к серверу возвращает готовый HTML-документ, сформированный на стороне сервера. Браузеру не нужно исполнять сложную логику для отображения страницы: он просто парсит полученную разметку. Это дает быстрое время первой отрисовки (FCP), поскольку контент появляется почти мгновенно. Но за это приходится платить полной перезагрузкой при каждом переходе. Каждая навигация означает новый запрос, новую передачу HTML и повторную инициализацию страницы. Пользовательский опыт страдает, особенно в динамических интерфейсах, где состояние приложения теряется при каждом переходе.

React как инструмент для SPA использует виртуальный DOM. Это легковесное представление реального DOM, которое хранится в памяти. Когда состояние компонента меняется, React сравнивает старый и новый виртуальные DOM и вычисляет минимальный набор изменений для реального DOM. Затем эти изменения применяются одним пакетом. Такой подход позволяет избежать дорогостоящих операций перерисовки всего дерева элементов. По данным официальной документации React, виртуальный DOM

сокращает количество операций с реальным DOM в среднем на 60-80% при типичных сценариях обновления списков. Компонентный подход дополняет эту модель: каждый компонент управляет собственным состоянием, а перерисовка происходит только для изменившихся компонентов, а не для всей страницы.

Django, напротив, полагается на серверный рендеринг через систему шаблонов. Шаблоны Django представляют собой HTML-файлы с тегами, которые подставляют значения из контекста. При обработке запроса Django выполняет три ключевые операции: сопоставляет URL с представлением, извлекает данные через ORM и рендерит шаблон. ORM (Object-Relational Mapping) здесь играет решающую роль. Он транслирует запросы к базе данных в Python-код, но цена этой абстракции, накладные расходы на преобразование. Например, сложный запрос с несколькими JOIN может генерировать дополнительные SQL-запросы, если не использовать методы вроде `select_related` или `prefetch_related`. Профилировщик Django Debug Toolbar показывает, что без оптимизации ORM количество запросов к базе на одну страницу может достигать 20-30, тогда как при грамотном использовании тех же методов оно снижается до 5-7.

Интересно, что обе архитектуры пытаются решить одну проблему разными способами. SPA переносит нагрузку на клиент, освобождая сервер от рендеринга, но увеличивая объем передаваемых данных. MPA оставляет рендеринг на сервере, что требует больших вычислительных ресурсов при каждом запросе, но уменьшает размер ответа. React и Django, это не просто фреймворки, а инструменты, которые кодируют эти архитектурные решения в код. Выбор между ними означает выбор между скоростью взаимодействия после загрузки и скоростью самой первой загрузки, между интерактивностью и простотой.

3. Методика эксперимента и инструментарий

После того как в предыдущей главе были описаны архитектурные различия, закономерно возникает вопрос, как эти различия измерить на практике. Для чистоты эксперимента были разработаны два функционально идентичных приложения: одно на React (SPA), другое на Django (MPA). Оба решают одну задачу: вывод списка товаров с фильтрацией по категории и поиском по названию. Такая функциональность типична для интернет-магазина, поэтому результаты теста имеют практическую ценность.

Ключевое условие эксперимента, идентичность набора данных. В обеих системах используется одна и та же база из 500 записей, сгенерированных случайным образом. Это исключает влияние объёма данных на итоговые метрики. Серверная часть также настроена одинаково: один и тот же веб-сервер, одинаковые настройки кэширования, одинаковое количество одновременных подключений.

Измеряются четыре основные метрики. TTFB (Time To First Byte) фиксирует задержку между запросом пользователя и первым байтом ответа от сервера. FCP (First Contentful Paint) показывает, когда на экране появляется первый видимый элемент контента. TTI (Time To Interactive) определяет момент, когда интерфейс полностью реагирует на действия пользователя. Дополнительно профилировщики Django записывают нагрузку на сервер: количество запросов в секунду и потребление процессорного времени.

Для измерения используются три независимых инструмента, что повышает достоверность данных. Google Lighthouse запускается в headless-режиме Chrome и даёт комплексную оценку по всем трём метрикам производительности. WebPageTest позволяет провести тесты с разных географических точек, хотя в данном эксперименте используется только один локальный сервер для контроля условий. Встроенные профилировщики Django, включая django-debug-toolbar, фиксируют время выполнения SQL-запросов и общую длительность обработки

каждого HTTP-запроса.

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

Измерения проводятся для трёх сценариев использования. Первый, холодный старт, когда браузер открывает приложение с пустым кэшем. Второй, тёплый старт, когда часть ресурсов уже загружена. Третий, навигация внутри приложения: переход на страницу товара и возврат обратно к списку. Для MPA это полноценные перезагрузки страниц, для SPA, клиентские переходы без обращения к серверу за HTML.

Особое внимание уделяется фиксации условий эксперимента. В лог записываются версии браузеров, операционной системы, Node.js и Python. Это позволяет воспроизвести результаты при необходимости. Полученные данные структурируются в таблицы, где каждая строка соответствует одному прогону, а столбцы, метрикам и условиям запуска. Дальнейший анализ этих таблиц будет представлен в следующей главе.

4. Анализ результатов и рекомендации

Измерения, описанные в предыдущей главе, дали неоднородную, но вполне ожидаемую картину. Первое и главное расхождение касается времени до первой отрисовки. Приложение на Django показывало FCP в диапазоне 0,8-1,2 секунды на стандартном наборе данных, тогда как React-приложению требовалось от 2,5 до 3,8 секунды. Разрыв объясняется тем, что серверный рендеринг отправляет готовый HTML сразу, а клиентский требует сначала скачать и выполнить значительный объём JavaScript. В тестах Lighthouse разница в показателе TTI (Time to Interactive) была ещё заметнее: MPA становилась интерактивной почти сразу после отрисовки, в то время как SPA требовала дополнительных 1,5-2 секунд на гидратацию и привязку обработчиков событий.

Однако после завершения начальной загрузки ситуация менялась радикально. При симуляции типичного пользовательского сценария (фильтрация списка, редактирование формы, обновление данных без перезагрузки страницы) SPA отвечала на действия за 50-100 миллисекунд. MPA в аналогичных условиях требовала 300-600 миллисекунд на каждый переход, поскольку браузер выполнял полный цикл навигации с повторной загрузкой ресурсов. Особенно наглядно это проявлялось при работе с таблицами данных. В приложении на React сортировка колонок происходила мгновенно, без видимых задержек. В версии на Django каждый клик по заголовку колонки вызывал перезагрузку страницы и заметную «белую вспышку». Для оператора, работающего с большим объёмом записей, эта разница выливалась в часы потерянного времени ежедневно.

Нагрузочное тестирование с помощью утилиты wrk выявило ещё одну закономерность. При 500 одновременных подключениях сервер Django стабильно обрабатывал около 1200 запросов в секунду, а среднее время ответа не превышало 90 миллисекунд. SPA-приложение при той же нагрузке генерировало в среднем 750 запросов в секунду, но это были запросы к API.

Критичным оказалось то, что каждый такой запрос требовал обработки на сервере, а также сериализации JSON и последующей работы с базой данных. В итоге серверная часть React-приложения упиралась в ограничения Python-бэкенда, и при росте нагрузки до 1000 пользователей время ответа API возрастало до 400-500 миллисекунд, что делало интерфейс ощутимо «задумчивым». MPA в этих условиях показывала более предсказуемую деградацию: страницы продолжали открываться, просто с несколько большей задержкой.

Эти результаты подтверждают выводы, к которым приходят исследователи из Оклендского университета в работе о производительности одностраничных приложений: выбор архитектуры определяется не абстрактным «лучше» или «хуже», а конкретным сценарием использования. Для интерфейса администратора, где пользователь совершает десятки действий в минуту и каждое ожидание воспринимается болезненно, SPA даёт ощутимый выигрыш в отзывчивости. Публичный сайт с новостными статьями или каталогом товаров, напротив, выигрывает от быстрой первой загрузки MPA. Показательно, что поисковые системы до сих пор лучше индексируют серверный HTML, а для контентных проектов это критично.

Практическая рекомендация, которая следует из эксперимента, довольно прямолинейна: не нужно выбирать что-то одно. Разумный компромисс выглядит как комбинированная архитектура. Публичные страницы: лендинг, блог, документация, каталог, реализуются как MPA на Django с серверным рендерингом. Это даёт быстрый первый отклик, хорошую индексацию и низкую нагрузку на инфраструктуру. Внутренние интерфейсы: личный кабинет, панель управления, аналитические дашборды, строятся как SPA на React, который общается с тем же Django-бэкендом через REST API. Такой подход позволяет получить лучшее от обеих архитектур, не жертвуя ни скоростью первой загрузки для внешних посетителей, ни отзывчивостью для постоянных пользователей.

Дополнительным аргументом в пользу гибридной схемы служит то, что она не требует переписывания кодовой базы. Django отлично справляется с ролью API-сервера, а React-клиент можно подключить к уже существующим моделям и представлениям. В результате команда получает масштабируемое решение, где каждая часть системы работает в оптимальном для неё режиме, а пользователь не задумывается о том, какая технология под капотом. В конечном счёте, именно этот показатель: отсутствие задержек там, где они мешают работе, и быстрое открытие там, где человек пришёл за информацией, определяет успех продукта.