Все мы знаем сайты с бесконечной прокруткой. Началось это безобразие с твиттера, потом дошло до Tumblr и далее везде. Пользователь докручивает страницу до низа, она снизу подгружается, и так без конца. Обычно это сопровождается отсутствием поиска по дате и вообще какого бы то ни было поиска.
Рано или поздно любая подобная страница начинает тормозить, потому что элементов в ней становится больше, чем способен вовремя обработать движок браузера и какие-то промежуточные скрипты на странице. Внимание, вопрос — а почему никто вместе с добавлением элементов в конец страницы не удаляет их из начала? То есть, после определённого количество "разрастаний" страницы, добавление каждого следующего элемента ленты влечёт за собой еще и удаление элемента из начала. В результате, страница будет иметь хоть и большой, но всё же конечный размер.
Делают ли так хоть где-нибудь, и есть ли в этом смысл вообще? Будет ли браузер освобождать память, которая была выделена под удалённые элементы DOM, или же окончательное освобождение памяти происходить только при закрытии вкладки/окна?
Здравствуйте, Слава, Вы писали:
С>Рано или поздно любая подобная страница начинает тормозить, потому что элементов в ней становится больше, чем способен вовремя обработать движок браузера и какие-то промежуточные скрипты на странице. Внимание, вопрос — а почему никто вместе с добавлением элементов в конец страницы не удаляет их из начала? То есть, после определённого количество "разрастаний" страницы, добавление каждого следующего элемента ленты влечёт за собой еще и удаление элемента из начала. В результате, страница будет иметь хоть и большой, но всё же конечный размер.
С>Делают ли так хоть где-нибудь, и есть ли в этом смысл вообще?
Ну если реально тормозит у пользователей и если это поможет, почему бы нет. Я с таким лично не сталкивался, не совсем понятно, о чём речь. Это какие-то слабые телефоны, у которых память заканчивается или что? Какой должна быть страница, чтобы сожрать всю память? Тормозить скорее будет из-за того, что добавление новых элементов вниз вызывает пересчёт layout-а всей страницы и этот процесс на слабых процессорах может снижать FPS. В общем я бы в первую очередь постарался понять, что именно тормозит.
> Будет ли браузер освобождать память, которая была выделена под удалённые элементы DOM
Здравствуйте, vsb, Вы писали:
vsb>Ну если реально тормозит у пользователей и если это поможет, почему бы нет. Я с таким лично не сталкивался, не совсем понятно, о чём речь. Это какие-то слабые телефоны, у которых память заканчивается или что? Какой должна быть страница, чтобы сожрать всю память? Тормозить скорее будет из-за того, что добавление новых элементов вниз вызывает пересчёт layout-а всей страницы и этот процесс на слабых процессорах может снижать FPS. В общем я бы в первую очередь постарался понять, что именно тормозит.
У вас есть вконтакт, возможно (я надеюсь). Откройте его, не на телефоне даже, а на десктопе. Полистайте новости ли, либо чью нибудь страницу постарее, прокручивайте вниз, вниз, вниз. Начнутся тормоза с того, что браузер отожрёт оперативки столько, что вступит в противоречие с дисковым кэшем. Раньше, когда браузеры были в основном 32битными, 2ГБ уже были пределом для процесса. Сейчас у меня запущен один браузер Firefox, он распределился на 7 процессов , занимают они, если в Far в списке процессов их выделить — 5.3 ГБ.
Да, и пересчёт layout'а — он очевидно не оптимизирован под гигантское количество элементов. Вы ведь помните, возможно, такую вещь из десктопной разработки — virtual grid, когда в таблице на экране отображались десятки тысяч строк, но на самом деле, они не хранились в виде строк той самой таблицы-контрола, которая видна на экране. Таблица была "скользящим окном" поверх настоящих данных, и это сильно ускоряло работу интерфейса, а то и было вообще единственным возможным способом заставить его отображать столь большое число элементов.
Здравствуйте, Слава, Вы писали:
С>(предупреждаю сразу — я не фронтендщик)
С>Все мы знаем сайты с бесконечной прокруткой. Началось это безобразие с твиттера, потом дошло до Tumblr и далее везде. Пользователь докручивает страницу до низа, она снизу подгружается, и так без конца. Обычно это сопровождается отсутствием поиска по дате и вообще какого бы то ни было поиска.
С>Рано или поздно любая подобная страница начинает тормозить, потому что элементов в ней становится больше, чем способен вовремя обработать движок браузера и какие-то промежуточные скрипты на странице. Внимание, вопрос — а почему никто вместе с добавлением элементов в конец страницы не удаляет их из начала? То есть, после определённого количество "разрастаний" страницы, добавление каждого следующего элемента ленты влечёт за собой еще и удаление элемента из начала. В результате, страница будет иметь хоть и большой, но всё же конечный размер.
С>Делают ли так хоть где-нибудь, и есть ли в этом смысл вообще? Будет ли браузер освобождать память, которая была выделена под удалённые элементы DOM, или же окончательное освобождение памяти происходить только при закрытии вкладки/окна?
1. Потому что заказчик об этом ничего не знает, он ставит задачу программисту, программист делает. Да тормоза, но задача выполнена, программист получил деньги, заказчик выполненную работу, все довольны кроме пользователей.
2. По поводу броузеров тут отдельная тема и вопрос для холивара: какой броузер сильней "течет"? У меня бывало FF с закрытыми вкладками до 1Гб отъедал. Опера при простое диск зачем-то постоянно начинает насиловать. Хромом пользуюсь редко.
3. И наконец камень в самих фронтендщиков ))) Имхо в большинстве случаев во фронтенд идут те, кто "ниасилил" стать нормальным программистом (я сам такой, потому знаю что говорю). Не хватает им порой знаний алгоритмов и структур, об оптимизации не думают абсолютно. Им надо фреймворками владеть, а не мозгами (я не такой если что )
С>Рано или поздно любая подобная страница начинает тормозить, потому что элементов в ней становится больше, чем способен вовремя обработать движок браузера и какие-то промежуточные скрипты на странице. Внимание, вопрос — а почему никто вместе с добавлением элементов в конец страницы не удаляет их из начала? То есть, после определённого количество "разрастаний" страницы, добавление каждого следующего элемента ленты влечёт за собой еще и удаление элемента из начала. В результате, страница будет иметь хоть и большой, но всё же конечный размер.
Здравствуйте, Слава, Вы писали:
С>Делают ли так хоть где-нибудь, и есть ли в этом смысл вообще? Будет ли браузер освобождать память, которая была выделена под удалённые элементы DOM, или же окончательное освобождение памяти происходить только при закрытии вкладки/окна?
Когда надо — делают. У нас в продукте в грид можно загрузить 100500 строчек и крутить туда-сюда. Количество единовременно отображаемых элементов не такое уж большое и работает вполне сносно.
Здравствуйте, Слава, Вы писали:
С>(предупреждаю сразу — я не фронтендщик)
С>Все мы знаем сайты с бесконечной прокруткой. Началось это безобразие с твиттера, потом дошло до Tumblr и далее везде. Пользователь докручивает страницу до низа, она снизу подгружается, и так без конца. Обычно это сопровождается отсутствием поиска по дате и вообще какого бы то ни было поиска.
Это "безобразие" мне напоминает микрософтовский риббон: нечто придумывается хорошо юзабелистами высокой квалификации, причем для определенных задач, но входит в моду, становится массовым и неизбежно доводится массами до абсурда. Взять, казалось бы, уважаемый Озон.ру. У них нужная информация находится в футере (о доставке, например), а при бесконечной странице футер тупо становится недоститжим, листание, кнопка "End" ... а он все валит свои бесконечные товары. Можно, конечно, открыть другую, короткую стр. и посмотреть, но ведь бред же . Я уже не говорю, что по памяти грузит не по-детски. На нормальных сайтах так не делается, конечно.
С>Рано или поздно любая подобная страница начинает тормозить, потому что элементов в ней становится больше, чем способен вовремя обработать движок браузера и какие-то промежуточные скрипты на странице. Внимание, вопрос — а почему никто вместе с добавлением элементов в конец страницы не удаляет их из начала? То есть, после определённого количество "разрастаний" страницы, добавление каждого следующего элемента ленты влечёт за собой еще и удаление элемента из начала. В результате, страница будет иметь хоть и большой, но всё же конечный размер.
Скорее на ум приходит не удаление объектов невидимых объектов, а их "скользящее переиспользование", т.е. когда на место невидимых объектов подгружаются видимые. Это может частично сэкономить ресурсы (а может не сэкономить — надо вникать).
С>Делают ли так хоть где-нибудь, и есть ли в этом смысл вообще? Будет ли браузер освобождать память, которая была выделена под удалённые элементы DOM, или же окончательное освобождение памяти происходить только при закрытии вкладки/окна?
Думаю, все усугубляется тем, что броузеров много. Разные движки со сборщиками мусора на разных платформах могут и работать по-разному — возможны нюансы. Ну и версии постоянно обновляются. Сегодня оптимизировал, а через год все начнет дохнуть. Лучше элементарно не использовать бесконечные стр. там, где данных реально много. Или предлпагать альтернативу, как, например, в некоторых магазитах, где одновременно есть и листание и кнопка "подгрузить еще", и все удобно.
Здравствуйте, Слава, Вы писали:
С>(предупреждаю сразу — я не фронтендщик) С>Все мы знаем сайты с бесконечной прокруткой.
отличный вопрос!
Смотрите в сторону игровых 2D (ну или если совсем хочется мега крутизны 3D)
В них эта проблема решена изначально, из коробки, иначе как делать платформеры?!
Там огроменные игровые вселенные скролятся плавно и незаметно
и можно играть (т.е. СКРОЛИТЬ) ЧАСАМИ !
Это точно есть в gamemaker 2D, Phaser js и в других
Просто если 2D игровой движок этого не умеет то он не игровой 2D движок.
Конечно это есть в 3D — юнити и анрил
А в дом есть шадоу-дом
возможно отправляя в тень то что выше и ниже экрана как-то можно совладать...
но готового решения из коробки — вроде нет, хотя не искал...
Кстати можно взглянуть на гугловский docs — там онлайн легко скролятся гигантские таблицы
Здравствуйте, koenig, Вы писали:
С>>Рано или поздно любая подобная страница начинает тормозить, потому что элементов в ней становится больше, чем способен вовремя обработать движок браузера и какие-то промежуточные скрипты на странице. Внимание, вопрос — а почему никто вместе с добавлением элементов в конец страницы не удаляет их из начала? То есть, после определённого количество "разрастаний" страницы, добавление каждого следующего элемента ленты влечёт за собой еще и удаление элемента из начала. В результате, страница будет иметь хоть и большой, но всё же конечный размер.
K>что будет, когда ты нажмешь home на клавиатуре?
Никто не мешает вставить в начало div высотой 10050000px. При нажатии home мы прыгнем наверх и начнём заново создавать элементы, которые попадают в окно просмотра.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
)
. Я уже не говорю, что по памяти грузит не по-детски. На нормальных сайтах так не делается, конечно.
