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

Question

[Станислав Гамаюнов]

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



Есть страница сервиса. На ней есть много инпутов, 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.



Заранее спасибо.

Answer 1

[Kane]

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

Comments

[Станислав Гамаюнов]

Грубо говоря, есть сущность, её представление — строка. В строке несколько дивов/спанов с текстом, пять инпутов, один селект, ещё свёрнутый див с доп. информацией — опять спаны. Это управление ценами.
Поиск используется только через ctrl+f, что бы быстро перейти к сущности с каким-то словом, или конкретным id, и ввести для неё какие-то особые значения. Выбирать из сущностей ничего не нужно, только переходить к ним на этой странице. А основное количество операций массовое. Редко на всё страницу, часто на группы сущностей по 2-40 штук. Строки изначально сгруппированы по группам. И способ объединения в группы только один, потому фильтры не актуальны.
Всё одновременно видеть нужно потому, что во-первых, очень важна общая картина, во-вторых, здесь же рядом с ценами выводится некоторое количество аналитики.
В общем любая попытка показывать не сразу всё приведёт к тому, что пользоваться этим станет сразу не удобно. У системы всего два пользователя, но весь интерфейс создавался именно в работе с ними и сейчас там всё так, как им удобно. Варианты с пагинацией и фильтрацией сразу же отметались.

Answer 2

[egorinsk]

Надо все же что-то поменять, чтобы HTML не весил 80 мегабайт и там не было 18 000 строк. Человек все равно не станет читать все эти тысячи строк.

Answer 3

[s0rr0w]

Перенос рендеринга со стороны сервера на клиента даст ухудшение скорости работы раз в 10 при таком количестве данных.

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

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

Если нужны будут еще какие-то консультации, лучше писать мне в скайп (в профиле) или в личку.

Comments

[Станислав Гамаюнов]

Проблему заполнения множества полей нужно решать не через jQ. Тут наиболее правильным путем будет кеширование ссылок на ноды и их перебор.

Тоже думаю в эту сторону. Спасибо. Сделаю так даже если в итоге внедрю пагинацию.

[s0rr0w]

Я бы посоветовал еще несколько поменять концепцию при работе с множественными данными. Поиск нужных строк можно сделать аналогично саджесту гугла. Все равно пользователь что-то ищет, хоть через Ctrl+F, хоть через любой другой инструмент.
Если нужно делать массовые операции, то лучше это производить через пакетные задачи. Пример такой пакетной задачи: выбрать все по такому-то фильтру и применить то-то. Это гораздо проще и контроллируемее, чем создавать аналоги на JS на стороне клиента. Кстати, пагинация приведет к проблеме, что некоторые действия придется делать для каждой страницы отдельно. Ну или в фоне, при помощи пакетных задач.

Answer 4

[Константин Китманов]

1. jQuery Templates заброшены и более не поддерживаются. Это надо учесть. Скорость у них не самая плохая, но вроде бы есть и побыстрее.
2. Рендерится оно будет действительно долго — клиентская машина скорее всего медленнее сервера. Можно сделать две вещи: отдавать клиенту заранее скомпилированные шаблоны (нет особого смысла, если шаблоны простые), и рендерить не сразу всё, а асинхронно кусками по 5 ваших строк.
3. Можно заменить пагинацию на «бесконечный» скроллинг. Поиск обеспечить другими средствами.

Comments

[Станислав Гамаюнов]

1. Конечно. jQuery Templates упоминал в роли синонима js-шаблонизаторов.
2. Рендерить кусками не понял зачем, если цель отрендерить страницу полностью любой ценой, то сразу всю будет быстрее ведь? Поиск не самое ценное, что потеряется, если показывать не сразу всё. Массовые операции гораздо важнее. Я бы даже сказал, что они критичны.

Понятно, что летать такое количество контролов всё равно не будет. Smarty делает fetch() почти 8 секунд, html весит > 80МБ и грузится в браузер полторы минуты (в gzip конечно меньше), после загрузки ещё секунд 20 работает js. И всё это жутко тормозит. Основной вопрос состоит в том, как это оптимизировать по максимуму. И довольно важно понять, стоит ли переходить на js-шаблоны.

[Константин Китманов]

Рендерить асинхронно кусками затем, чтоб браузер не вис на те 40 секунд, пока работает JS.

Answer 5

[blare]

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

Answer 6

[Ogra]

18 000 строк? Это, все-таки, перебор.
Можно делать асинхронную загрузку отображаемого контента — а массовыми операциями пусть занимается сервер, ему это — раз плюнуть. Если у вас поиск идет по Ctrl-f, то сгенерируйте страницу только с id && name, а цены пускай грузятся «по требованию».
Можно написать клиента на C#.

Comments

[Станислав Гамаюнов]

Спасибо. Решение о внедрении пагинации и фильтрации по другим параметрам вместо одной большой страницы уже начинает приживаться в моей голове.

Answer 7

[Иван]

Наверняка некоторые элементы повторяются на странице для каждой строки (я про эти пять инпутов). Почему бы не вынести их в отдельный Popup, а данные для отдельных элементов не хранить в JS или в hidden? И отдавать данные JSON'ом будет проще…

Answer 8

[karellen]

Вы сделали Эксель в браузере?

Comments

[karellen]

Если серьезно, похоже, вашим товароведам нужна нормальная программа управления инвентарем. Будет это 1С, Эксель или SAP — решать вам по вашим исходным данным. Сейчас вся схема звучит очень шатко, наверняка не способна бороться с вылетами и зависаниями браузера, случайными уходами и нажатиями и т.п. И мой коммент про Эксель может заиграть новыми красками, если вы, например, используете Excel external connection и действительно дадите людям управлять товарами через него, раз им так хочется иметь Ctrl+F. Есть и облачный вариант MS Office 365 Excel.

[Станислав Гамаюнов]

У нас немного другая тема. Мы управляем ставками в Яндекс.Директ. Серверная часть много общается с их API, а клиентская позволяет редактировать ставки и другие параметры быстрее веб-интерфейса Яндекса.
Потому 1С, SAP, с учётом уже сделанного, не подойдут.
А за указание на работу Excel с внешними данными спасибо. Полезные знания для кругозора.

[Александр Чекалин]

Вообще, подойдет любой язык программирования (это я к 1с и прочим — язык как язык, со своими расширениями, конечно).

Другой вопрос, что даже на GUI-ной экранной форме 18000 полей ввода выглядят перебором. Тот же Excel имеет grid, а не много-много независимых полей ввода, иначе бы и его никогда не прокрутили.

Но идея с пагинацией или ее эмуляцией (input-ы на месте остаются, а их содержимое обновляется, создавая иллюзию, что данные «прокручиваются» сквозь экран) кажется здравой. Сделайте просто поиск (свой, т.е. не через поиск на странице в браузере) — может, это поможет делу?..

Answer 9

[Skull]

Вариантов оптимизации очень много, для начала хотя бы кешировать сгенерированные темплейты в смарти + оптимизировать верстку. Я когда-то из 5 МБ html сделал 2 простым переименованием классов и минимизацией верстки. Уже будет не 80 МБ.

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