Они наверное в лисе сидят (в ней не тормозит ни прокрутка ни поле ввода) и посмотреть в хроме (подвержены все на blink) им судя по всему лень (не в их компетенции).
Да стандартная ситуация когда некомпетентные люди отфутболивают.
P.S. Вы так или иначе придёте к удалению лишнего из DOM, поэтому мне непонятно ваше категорическое «Нет», с отмеркой сколько нужно вешать в граммах.
И сколько предлагаете держать в «буфере» комментариев? всего сотню? (на сотне наверное не тормозит?) А знаете что при динамической видимой области перестаёт полноценно работать поиск по CTRL+F? То есть тут уже встают две задачи сделать динамическую область видимости (задача сама по себе не простая) и ещё эмуляцию поиска (который будет искать и в невидимых комментариях). А технический долг в виде перегруженной каскадной таблице стилей никуда не исчезнет.
Так-то я за динамическую область видимости, но только когда в ней есть потребность.
Решение проблемы в данном случае заключается в удалении из DOM лишних комментариев, невидимых на странице
Нет, решение для поле ввода заключается в чистке неиспользуемых стилей и возможно рефакторинга переусложнённых селекторов (их хватает неоптимальных), а прокрутка и вовсе чинится так.
Динамический viewport нужен только когда у вас реально много данных на странице (начиная с десятка тысяч, или даже больше), а тут на момент написания этого комментария всего 1369 комментариев.
Можно еще при прокрутке всей странице задавать mouse-events:none;
Да, это тоже можно, но в данном случае не обязательно, достаточно обойтись стилями выше и тормоза при прокрутке сразу уходят.
А вот тормоза с полем ввода без рефакторинга не избежать, ибо проблема даже не в количестве тормозных селекторов (а их реально много), а в самом по себе огромном количестве селекторов (даже те селекторы которые не используются на странице всё равно добавляют тормозов).
Кстати я отписал таки в тп хабра, цитирую ответ: «Вы можете привести пример ресурса на котором статьи с 1300 комментариев загружаются на ваш компьютер без задержек?»
Я конечно могу быть не прав, извините, но меня чуть не вывернуло от такого ответа от тп именно хабра.
Почему комментарии так безбожно тормозят? Неужели отрендерить 1000 комментов это такая сложная задача? Почему когда я их прокручиваю (хром, винда), оно тормозит так будто биткоины майнит и почему когда я прокручиваю огромный RFC всё летает?
Я ответил тут почему.
Вкратце: на хабре очень много не оптимальных стилей.
Хотите секрет? Это всё CSS (СТИЛИ) виноваты. Грохните их dr.habracdn.net/habrcom/styles/1537449801/main.bundle.css и всё станет в сто раз шустрее. Можно через F12 во вкладке Source открыть и потереть содержимое этого файла или перейти через Elements на него в стилях элемента какого-нибудь.
Это не новая проблема. Частенько всякие там кривые нормализаторы (сброс стилей) сильно так тормозов добавляют (но в данном случае проблема глубже). Уже не в первый раз вижу такое на сайтах.
Сильно от игры/движка зависит. Современные движки уже многопоточны. Даже игровую логику можно сделать многопоточной, например в юнити есть C# Job System.
Лучше чем Sublime (возможно от версии зависит). У меня саблим долго грузил и падал на файле 131МБ, а vscode свободно открыл (предупредил о возможных тормозах и предложил отключить подсветку, я не стал этого делать и так норм работает, только памяти выжирает не мало) и в отличие от n++ сворачивал и разворачивал огромные ветки/узды без особых тормозов (в n++ они были минутами).
Ну я дал пруф.
А гугл реально уже убил URL, пока правда для макоси только, для винды надо включать chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains
ибо на той же версии у меня из коробки не получилось словить. Возможно они уже как-то хитро поменяли поведение по умолчанию.
Это полный бред вырезать www и m из поддоменов.
m.example.www.example.com внешне превращается в example.example.com
Да стандартная ситуация когда некомпетентные люди отфутболивают.
Так-то я за динамическую область видимости, но только когда в ней есть потребность.
Динамический viewport нужен только когда у вас реально много данных на странице (начиная с десятка тысяч, или даже больше), а тут на момент написания этого комментария всего 1369 комментариев.
А вот тормоза с полем ввода без рефакторинга не избежать, ибо проблема даже не в количестве тормозных селекторов (а их реально много), а в самом по себе огромном количестве селекторов (даже те селекторы которые не используются на странице всё равно добавляют тормозов).
«Круто», что тут ещё сказать.
deniskin, это норм?
По большей части чтобы устранить тормоза прокрутки наберите в консоле (через F12):
C полем ввода сложнее, я пока не понял какие стили гробят.
Вкратце: на хабре очень много не оптимальных стилей.
Это не новая проблема. Частенько всякие там кривые нормализаторы (сброс стилей) сильно так тормозов добавляют (но в данном случае проблема глубже). Уже не в первый раз вижу такое на сайтах.
Сильно от игры/движка зависит. Современные движки уже многопоточны. Даже игровую логику можно сделать многопоточной, например в юнити есть C# Job System.
А гугл реально уже убил URL, пока правда для макоси только, для винды надо включать chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains
ибо на той же версии у меня из коробки не получилось словить. Возможно они уже как-то хитро поменяли поведение по умолчанию.
Это полный бред вырезать www и m из поддоменов.
m.example.www.example.com внешне превращается в example.example.com
А ещё Ice Age Scrat Story.avi, gopher.wmv…