happyproff
@happyproff
Счастливый веб-разработчик

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

Приветствую.

Есть страница сервиса. На ней есть много инпутов, span с числами, кнопок. По кнопкам происходят действия, например:
  • заполнение всех инпутов определенного класса значением из другого инпута значением
  • обхода инпутов, сбора их значений и data-атрибутов в массивы, отправка аяксом на сервер
  • отправка аяксом только выделенных строк или строк, сгруппированных по родителю (типа раздела)

Проблема в том, что строк (дивов с пятью инпутами, кучей другого html) больше 18 000. Пока строк было несколько сотен, всё работало быстро. Но теперь во-первых, шаблонизатор (Smarty) генерирует страницу за ~8 секунд, html на выходе весит >80 мегабайт, всё это грузится по полторы-две минуты и еле как скроллится в браузере. К тому же, при некоторых действиях, упираюсь в js ошибку maximum call stack size exceeded. Конечно на сервере есть gzip сжатие, но не особо оно и помогает.

Очевидно пора что-то менять :)

Возможные варианты:
  • Отдавать с сервера на клиент .json с голыми данными, на клиенте формировать контролы с помощью jQuery Templates.
  • Пытаться сократить количество элементов в html. Возможно будет выигрыш, но, кажется, совсем небольшой.
  • Пагинация. Но отметается, т.к. в массовых операциях, ctrl+f и подобном самый кайф.
  • Последний в моём списке, но наверняка первый по приоритету пункт: сейчас у меня например такие конструкции: $(selector).on('click', function(){// some code});. Как следствие, около тысячи обработчиков. И таких тысяч больше одной. Очевидно, что нужно переписать это на $('body').on('click', selector, function(){// some code});


У кого есть опыт, знания, подскажите, рационально ли вообще применять здесь jQuery Templates, какие стратегии нужно применять при работе с таким количеством данных, элементов и обработчиков. Очень не хотелось бы переписать всё на json+templates и обнаружить, что грузится оно за 3 секунды, но рендерится 40.

Заранее спасибо.
  • Вопрос задан
  • 2984 просмотра
Пригласить эксперта
Ответы на вопрос 9
@Kane
Не совсем понятно что именно вы делаете и зачем всю эту кучу данных видеть одновременно, но на первый взгляд это выглядит так, как будто вам нужен нормальный поиск по всем этим данным на стороне сервера.
Ответ написан
@egorinsk
Надо все же что-то поменять, чтобы HTML не весил 80 мегабайт и там не было 18 000 строк. Человек все равно не станет читать все эти тысячи строк.
Ответ написан
@s0rr0w
Перенос рендеринга со стороны сервера на клиента даст ухудшение скорости работы раз в 10 при таком количестве данных.

Нужно решать проблему несколькими способами
1. В smarty2 отказаться от include, перейти на defun/fun плагин (если include используется)
2. В smarty3 постараться уменьшить количество функций, если их много и они маленькие
3. По минимуму свести генерацию темплейтов на стороне клиента
4. Так как оператору не нужно все и сразу, можно разбить интерфейс на множество мелких частей, и загружать их по требовани. в виде готового html.
5. Проблему заполнения множества полей нужно решать не через jQ. Тут наиболее правильным путем будет кеширование ссылок на ноды и их перебор. Лично я использую свои инструменты для этого, в которых кеширование сделано из коробки
6. Отказ от «ненавязчивого» подхода навешивания обработчиков и переход к старому доброму , чтобы не использовать live-методы навешивания обработчиков.

Максимум нод, которые переваривает браузер, нужно держать в районе 10-20К.

Если нужны будут еще какие-то консультации, лучше писать мне в скайп (в профиле) или в личку.
Ответ написан
k12th
@k12th
console.log(`You're pulling my leg, right?`);
1. jQuery Templates заброшены и более не поддерживаются. Это надо учесть. Скорость у них не самая плохая, но вроде бы есть и побыстрее.
2. Рендерится оно будет действительно долго — клиентская машина скорее всего медленнее сервера. Можно сделать две вещи: отдавать клиенту заранее скомпилированные шаблоны (нет особого смысла, если шаблоны простые), и рендерить не сразу всё, а асинхронно кусками по 5 ваших строк.
3. Можно заменить пагинацию на «бесконечный» скроллинг. Поиск обеспечить другими средствами.
Ответ написан
blare
@blare
Если проблема постранички только в поиске, то как сказано выше, вам нужно сделать нормальный поиск на ajax.
Либо эта задача как-то решается по другому, но нужно знать для чего все это.
Ответ написан
Ogra
@Ogra
18 000 строк? Это, все-таки, перебор.
Можно делать асинхронную загрузку отображаемого контента — а массовыми операциями пусть занимается сервер, ему это — раз плюнуть. Если у вас поиск идет по Ctrl-f, то сгенерируйте страницу только с id && name, а цены пускай грузятся «по требованию».
Можно написать клиента на C#.
Ответ написан
dohlik
@dohlik
Наверняка некоторые элементы повторяются на странице для каждой строки (я про эти пять инпутов). Почему бы не вынести их в отдельный Popup, а данные для отдельных элементов не хранить в JS или в hidden? И отдавать данные JSON'ом будет проще…
Ответ написан
karellen
@karellen
Вы сделали Эксель в браузере?
Ответ написан
Skull
@Skull
Вариантов оптимизации очень много, для начала хотя бы кешировать сгенерированные темплейты в смарти + оптимизировать верстку. Я когда-то из 5 МБ html сделал 2 простым переименованием классов и минимизацией верстки. Уже будет не 80 МБ.

Проблему нужно решать в другую сторону, а если через год там будет 50 000 строк? Нарастите оперативы на клиентских машинах? Убедите заказчика сделать динамические ajax-таблицы — они и миллион строк переварят — github.com/claushellsing/JqTable
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы
RailCommerce Москва
от 120 000 до 170 000 руб.
ТМК Нижний Новгород
До 100 000 руб.
18 июля 2018, в 22:20
4000 руб./за проект
18 июля 2018, в 21:54
1000 руб./в час