Как правильно прописать критерии загрузки веб-приложения в договоре?

Question

[asnarskiy]

Всем привет,

мы заказывали у студии разработку веб-приложения. У приложения относительно большая логика (10 тысяч редактируемых строк в БД, связанных условиями), первый раз главная страница прогружалась около 40 секунд, после чего приложение работало быстро.

Затем, студия что-то там "закешировала" и загрузка сократилась до 3-6 секунд на десктопе и 12 сек на смартфоне при 4g (что критично)

Наша аудитория в основном заходит с мобильных. Теперь, мы готовы внести доработки по оптимизации скорости, но не знаем, как именно это прописать в договоре.
Формулировка у студии "оптимизируем скорость" на наш взгляд размыта. Возникло несколько вопросов:

— Как именно прописать "быструю загрузку" в доп. соглашении? Нужно ли привязываться к каким-то конкретным цифрам, например: "приложение должно загружаться при slow 3g за столько-то секунд", или это чушь?

— Насколько реально сделать 1-2 секундную загрузку на смартфонах приложений на vue + yii2?

Возможно, вопросы не совсем корректные, но будем признательны за любые полезные комментарии. (-:
Не хотим заплатить и получить медленный продукт.

Answer 1

[ThunderCat]

во первых - скорость загрузки зависит от 3 параметров:
1) Скорость исполнения кода на сервере, которая в свою очередь делится на собственно код, и запросы к бд ( которые чаще всего и создают основную нагрузку и тормоза).
2) Скорость передачи данных и объем данных. Первое зависит от расположения сервера, удаленности от точки запроса, канала сервера и канала клиента. Второе, как вы понимаете, обычно зависит от качества и объема кода (html/js/json/картинки), передаваемых от сервера к клиенту.
3) Рендер страницы. Зависит от подключаемых скриптов / стилей, блокировок жс кода и объема и сложности разметки.

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

Для примерной оценки работы вашего сервиса я бы сравнил ваши показатели с примерно схожими крупными аналогами вашего сайта.

первый раз главная страница прогружалась около 40 секунд

Это ад, не должно так быть в любом случае. Явно говорит о том что архитектура или не продумана, или явно сляпана на коленке, в надежде что "кэш все вытянет".

Comments

[freeExec]

Ну тут не понятно, первый раз за каждый сеанс работы или первый раз при развёртывания базы.

[ThunderCat]

freeExec, легко проверяется заходом из инкогнито, и вообще - что значит развертывание базы? База должна быть развернута задолго до релиза или первого захода клиента, это какой-то нонсенс. Первый заход скорее всего прогревал кэш и "показал все на что способен" без него, то есть запросы в бд по 5-6 секунд, код с запросами в циклах и библиотеки js по 15 мегабайт... Это не факт, так, предположение, но я с таким уже несколько раз сталкивался.

[asnarskiy]

ThunderCat благодарю за обратную связь.

Answer 2

[d'Ivan]

Быстро - понятие расплывчатое, но, в целом, по-моему, это до 2-х сек. загрузка основного контента, при котором можно уже работать комфортно.
Хорошо разработанное веб-приложение:

1. не "вешает" браузер
   
2. имеет небольшой объем статических файлов в совокупности (такой, который позволяет получить почти весь контент за эти 2 сек.) при первом посещении
   
3. имеет небольшое количество статических файлов и для этого компонует множество статических файлов в несколько файлов bundle с целью уменьшения количества обращений к серверу
   
4. загружает статические файлы с серверов CDN расположенных географически близко к основной аудитории приложения
   
5. имеет клиентскую часть с минимизированным обращением к серверу для обмена информации
   
6. сервер отдает ответ макс. до 100 мс (в локальной сети веб-приложения). С учетом задержек сети (network latency) в реалиях мобильного интернета можно возрасти время получения ответа в разы.
   
7. при длительных операциях информирует пользователя о статусе
   

Нужно разделять время отдачи ответа сервером и время прохождения от сервера к клиенту.

Comments

[asnarskiy]

Благодарю за обратную связь.

Answer 3

[Армянское Радио]

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

Чтобы получить представление о том, что туда писать, потыкайте конкурентов этим сервисом - получите представление о том, какие времена вообще бывают.

Время - скорее около 3-6 секунд, нежели 1-2. Помимо этого, будут разные профили работы для разных ситуаций:

Например, если вы ориентированы на жителей Москвы и СПБ, вы можете получить дополнительный выигрыш, разместив серверы прямо в этих городах.

Comments

[asnarskiy]

Благодарю за ответ.