Как стать автором
Обновить

Вы можете себе это позволить? Бюджет веб-производительности в реальном мире

Время на прочтение15 мин
Количество просмотров16K
Всего голосов 30: ↑29 и ↓1+28
Комментарии44

Комментарии 44

Иногда начинало казаться что мы идём к тому, что все сайты будут тестироваться в сетях 100+ Мбит/с, <5 мс задержки, только топовом железе и только последних браузерах.
НЛО прилетело и опубликовало эту надпись здесь
Ладно инстаграм, они не захотели нагружать и без того нагруженные сервера генерацией HTML-кода и перенесли весь рендеринг в браузер. А нахрена SPA всем остальным?
Мне кажется что spa прежде всего для пользователей, так как пропадает раздражающая перезагрузка, которая к тому же задерживает рендер. Кроме того, интерактив (изменении информации вреальном времени), без которого сложно представить современное приложение, будет очень задерживать рендер из-за своей «неповоротливости». Ещё мне как разработчику больше нравится spa.
пропадает раздражающая перезагрузка

Я уже писал об этом ранее: просто подгружаем кусок HTML-кода аяксом и пихаем на страницу — всё, раздражающая перезагрузка пропала. Скрипт килобайт на десять максимум, с учётом костылей под все браузеры. Так уже делают ВК и гитхаб, например


интерактив

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

НЛО прилетело и опубликовало эту надпись здесь
Для справки, у меня скрипт для полной аяксификации сайта (велосипед-аналог pjax) весит 50кб со всеми костылями и документацией, с минификацией и гзипом ужался в 1.6кб)

Проба сжатия на скорую руку остальных скриптов одного крупного сайта дала 55кб, но тут в лоб не совсем корректно сравнивать, нужно ещё фичастость учитывать

А если надо перезагрузить контент не в одном блоке, а в разных местах страницы?


Так уже делают ВК и гитхаб, например

Регулярно натыкаюсь в ВК на такие баги. После нескольких переходов по страницам состояние нотификаций и текущего трека в шапке сайта одно, а внизу в коненте — другое. А все как раз потому, что данные приходят с сервера отдельными кусочками и не синхронизируются, в отличие от нормальных SPA, где все рендерится из единого стора.

А если надо перезагрузить контент не в одном блоке, а в разных местах страницы?

Загружаем несколько контентов, делов-то


состояние нотификаций и текущего трека в шапке сайта одно, а внизу в коненте — другое

Лично я с этим не сталкивался, но поверю, что оно есть. Ничто не мешает подгружать куски HTML-кода и поменять ему пару классов согласно информации из единого стора. То, что разработчики ВК так не сделали (если правда не сделали) — их личные проблемы.

А можете рассказать поподробнее? Я смотрю документацию pjax и вижу, что там можно обновить только один контейнер по клику:


$('.group-invite-accept').on('click', event => {
    $.pjax.submit(event, '#pjax-container');
});

Как в вашей имплементации можно обновить несколько блоков? И где будет написано по какому url какой блок забирать?

pjax хрень, но ничего не мешает сделать (и я делал) аналог, позволяющий передавать несколько контентов, мыслите абстрактнее и не зацикливайтесь на конкретной реализации :)


И где будет написано по какому url какой блок забирать?

А это вообще зачем?

Так расскажите поподробнее о своей реализации! Как будет выглядеть перезагрузка нескольких контейнеров в примере кода выше?


Все варианты, что я сейчас могу придумать, похожи на спагетти-код.

Как будет выглядеть перезагрузка нескольких контейнеров в примере кода выше?

Я ещё не понял, какая задача решается? Возможно, вы пытаетесь впихнуть pjax туда, где достаточно простого fetch (и совсем необязательно это будет спагетти-код, если руки не кривы)

Я ещё не понял, какая задача решается?

Что-нибудь как в ВК, есть центральный контент, а есть левое меню. Нужно счетчики слева обновлять, например когда приглашение в группу принято, нужно там новую цифру подгрузить.

Нет смысла юзать для этого pjax. Центральный контент пусть подгружается как HTML-код с pjax'ом, а счётчики простыми числами гоняются по каким-нибудь вебсокетам (быть может, с хранением их в едином сторе, тут архитектура уже на свой вкус). Поменять пару классов и textContent'ов по событию из вебсокетов или из стора — задача элементарная, реактов и ангуляров не требующая.

Ага, то есть все-таки надо будет написать сколько-то клиентского кода, а не


просто подгружаем кусок HTML-кода аяксом и пихаем на страницу

как вы писали ранее.


В итоге так все равно получаем большой js-бандл с лапшой из селекторов в разные места страницы, "зато не на реакте", прекрасно.

Зависит от задачи, очевидно же. Pjax-подобные решения покрывают процентов девяносто задач, для остального, если вы внимательно читали мои комментарии, я и сам накатал 55кб сжатого жс-кода на одном большом сайте. С реактом получилось бы раз в пять больше.

Если вы не умеете писать на js и ваш код с селекторами постоянно получается лапшой — это ваши личные проблемы с вашей кривизной рук, уж простите ¯\_(ツ)_/¯

Конечно, у всех кривые руки, один вы профессионал. Вот Хабрахабр например. На эту страницу грузится ~80 Кб кода на Jquery (не считая веса библиотек). И все равно встречаются вот такие баги.


Можно сколько угодно пенять на кривые руки, а можно сделать рендер комментариев из json полностью на клиенте и исключить такую проблему в принципе.

Рендер на клиенте от «таких багов» не поможет. Забыли обновить статус прочитанности в сторе — всё, получаем тот же баг.
Проверил сейчас сайты нескольких популярных европейских интернет-магазинов, которыми пользуюсь. Все сделаны по классической схеме с рендерингом на сервере + вкрапления ajax в некоторых элементах. Перезагрузка вообще не раздражает, поскольку происходит практически мгновенно. Щелк — лаг 0.5-1 сек — и новая страница открылась. Картинки, конечно, догружаются ещё пару-тройку секунд, но страница в это время уже полностью дееспособна. Это в 100 раз круче, чем наблюдать долбаные спиннеры. И это при том, что все эти сайты (я немного посмотрел в дев-тулс) ещё далеко не идеалы оптимизации, ещё есть что улучшить.
Всё верно, SPA для интернет-магазинов — зло. Использование магазина подзумевает открытие нескольких вкладок для выбра товара. Не очень приятно при каждом открытии вкладки ожидать её прогрузки, потому что какой-то недальновидный программист решил магазин оформить как SPA.

Ещё бесит SPA в почтовиках (типа gmail).

SPA нужно использовать только там, где это действительно оправдано, а не лепить везде, потому что это модно.
НЛО прилетело и опубликовало эту надпись здесь
То есть SPA в вашем понимании не включает в себя изоморфизм?

Не могу дать ответа на вопрос, я не веб-разработчик, для меня изоморфизм — это понятие из теории графов.


SPA в моём понимании — сайты, где многооконность сознательно огорожена программистом: невозможность открытия письма в новой вкладке, потеря состояния и рассинхронизация при работе сразу в нескольких вкладках и т.д.


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


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

НЛО прилетело и опубликовало эту надпись здесь
Хорошо, как же тогда назвать одностраничные приложения, которые позволяют и открывать отдельные страницы в новой вкладке, и синхронизируются между вкладками, и не требуют ожидания прогрузки данных в странице?

Не знаю. Но если основной сценарий работы с сайтом предполагает открытие множества специализированных страниц, то какой смысл его реализовывать как SPA?

И весь-весь нативный функционал работает? Как например открыть ссылку в новой вкладке (через контекстное меню и через ctrl+click), новом окне, новом приватном окне, добавить в закладки, сохранить объект как…
НЛО прилетело и опубликовало эту надпись здесь
В нормально сделанном SPA всё так и есть. Правда, ненормальные попадаются как-то чаще)
Так и понятно почему. Реализовать-то можно если не всё, то почти всё. Но это адовый объем работы с непонятной мотивацией — на коленке реализовать и отладить всё то, что нативно в браузере есть из коробки. Но обладает фатальным недостатком.

Не стоит недооценивать человеческую лень :). Я, например, как разработчик backend'а, особенно не на PHP, с радостью полностью избавился от необходимости рендерить HTML на сервере. Когда JavaScript всё равно «знает» про то, какие элементы есть на страницах, намного удобнее сделать так, чтобы сам JavaScript его и рендерил — это сильно уменьшает необходимость в общении между фронтенд-разработчиками и бэкенд-разработчиками. Заодно можно сделать мобильные и десктопные клиенты, которые будут пользоваться тем же API — не красота ли?


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

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

И да, рендеринг HTML на сервере избавляет от необходимости иметь JavaScript вообще, на радость параноикам c NoScript ;)
НЛО прилетело и опубликовало эту надпись здесь
Я правильно понимаю, что вы подразумеваете реакт на сервере? Тогда может быть. Но мне это кажется лишь усложнением)
НЛО прилетело и опубликовало эту надпись здесь
Ну, в контексте ветки ничем? Я начал ветку примерно с того, что шаблонизатор в браузере нафиг не нужен)
Неужели проблема с рендерингом HTML настолько серьёзна? Я всегда считал, что самое тяжёлое — это работа с базой и бизнес логика, а расходы на преобразование данных в HTML малозначимы.
Когда счёт идёт на миллионы запросов в секунду и больше, даже что-то малозначимое начинает означать нагрузку на несколько мощных серверов, на которых бизнес будет очень рад сэкономить)
Если это обернётся снижением числа пользователей (нагрузка на клиенты-то возрастёт), то экономия получится сомнительной.
Мне обычно рассказывают, что становится наоборот быстрее и повышеннее. Правда, в сравнении с «обычными» сайтами; сравнений с pjax-подобными вещами я не встречал
Когда-нибудь до них дойдёт, что SPA с тонким бэкэндом — мертворожденный уродец…
НЛО прилетело и опубликовало эту надпись здесь
Я всё чаще встречаю попытки вытащить на фронт вообще всё, кроме непосредственно общения с БД.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации