Если у вас еще не было возможности заглянуть в Intersection Observer API, это определенно стоит посмотреть. В двух словах, это позволяет добавить слушателя к целевому элементу. Когда этот элемент становится видимым для области просмотра устройства (или указанного элемента), вызывается ваш обратный вызов.
Как это связано со временем загрузки страницы, о котором вы говорите? Что ж, мой социально дистанцированный друг, я рад, что ты спросил. Для начала, если вы можете отправить меньше кода в браузер, сделайте это, это всегда выигрыш. Меньше материала для рендеринга почти всегда означает более быстрые страницы. Что, если вам нужно отображать много данных в виде таблицы или списка… что тогда?? Разбивка на страницы, безусловно, вариант, но это не решает всех проблем. Рассмотрите возможность показа контента только тогда, когда он был виден (или почти виден).
[отключение микрофона]
А если серьезно, скажем, вы хотите создать список типа бесконечной прокрутки, в котором следующая страница (или набор) данных извлекается только после того, как пользователь прокрутит до конца текущего списка. Традиционно вы должны настроить прослушиватель события прокрутки и определить, находится ли позиция прокрутки в нижней части вашего списка, прежде чем выбирать следующую страницу. Даже если вы отменили (по сути, дросселировали) свое событие прокрутки, вы все равно просматриваете, вероятно, десятки, если не сотни ненужных проверок положения прокрутки. Принимая во внимание, что прикрепление наблюдателя к n-му элементу с конца вашего списка и вызов вашего обратного вызова один раз, когда он становится видимым, является гораздо более счастливым местом.
Следующий сценарий может иметь yуууууууууууууууууууууууууууууууууууууууууууу ни эффективность.
Давайте изучим большие наборы данных. Недавно я настроил страницу, которая требовала отображения огромного количества карточек в сетке. Этот список может вырасти до более чем 100 000 пунктов. Хотя можно было бы использовать разбиение на страницы, если пользователь прокручивал список, все еще оставалось огромное количество элементов, отображаемых в DOM, что в различных ситуациях приводит к более медленному, чем приемлемое, времени отклика. Виртуальные списки также могут стать причиной дополнительных головных болей. Я надеялся найти другую альтернативу.
Чтобы улучшить взаимодействие с пользователем, мы решили использовать Intersection Observer для отображения только видимых элементов на странице. Кроме того, мы создали «фрагменты» элементов (около 100 элементов в каждом фрагменте), что позволяет сократить количество итераций по невидимым элементам. Это позволяет пользователю получить воспринимаемый мгновенный ответ от пользовательского интерфейса, а также не раздувать DOM элементами, которые никогда не будут видны.
Если вам интересно увидеть пример этой установки, дайте мне знать в комментариях, и я мог бы создать еще один пост или видео об этом.
С помощью Intersection Observer API можно сделать очень много вещей, и несколько довольно крутых примеров показаны в документах на MDN. Имея широкую поддержку браузера, попробовать, безусловно, стоит.
