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.



Заранее спасибо.
  • Вопрос задан
  • 3011 просмотров
Пригласить эксперта
Ответы на вопрос 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
Ответ написан
Комментировать
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы