Использование JavaScript и onload-события для создания «самостоятельных» сайтов

Сервер формирует страницу и отправляет ее браузеру, когда на сайт пришел посетитель. Совокупная логика всех страниц сайта определяет функциональность веб-ресурса и интерес к нему посетителей.

Использование JavaScript и onload-события кардинально меняет функционирование сайта. Если на момент окончания начальной загрузки назначить обработчик, то можно определить, с чего именно, как именно и что следует начинать делать.

Главное событие страницы

Окончание загрузки страницы фиксируется событием onload, которое назначается тегу body. Наступлению данного события предшествует загрузка всех стилевых файлов, скриптов, изображений и других ресурсов. Дерево элементов страницы (DOM) построено, но может быть не отображено в окне браузера.

В HTML-синтаксисе и на языке JavaScript onload и body — одно целое. Событие окончания загрузки возникает, как только тело документа со всеми сопутствующими файлами (ресурсами) загружено и готово к использованию.

В примере показано, как подключить обработчик события onload на JavaScript. Слева код HTML-страницы. Тегу body назначен обработчик GoPage(). Справа код обработчика — обычная функция языка браузера с «необычным» функционалом.

Простой пример использования onload

Пример простой и показательный. Здесь нет конкретной логики, а механизм обработки события onload на JavaScript показан на востребованной задаче — ориентация элементов страницы в окне браузера конкретного размера.

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

Сразу после тега body идет описание требуемых переменных, содержащих текущие: высоту и ширину окна, координаты шапки, содержания и футера страницы. Переменные только описаны, реальные значения они получают при обработке события onload в JavaScript функции GoPage().

Смысл примера в том, чтобы при загрузке страницы получить нужные начальные данные и обеспечить выполнение функции scfChange(). Эта функция назначается обработчиком на событие onresize и запускается каждый раз, когда меняется размер окна браузера.

Результат примера: событие onload на JavaScript вызывает установку начальных значений, что обеспечивает правильное функционирование scfChange() и запускает обращение к серверу «InitXML( …» для принятия следующих действий.

Проблема логики использования события onload

Посетитель приходит на сайт, страница загружается, срабатывает событие onload, и выполняются все подготовительные действия. Логика работы после отработки onload зависит от логики сайта и его функционального назначения.

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

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

Нет никакой гарантии, что завсегдатай сайта или новый посетитель не выберет обновление страницы. А это тоже событие onload, и JavaScript функции придется «уметь» различать первоначальную загрузку страницы от ее обновления. Это не большая проблема в программировании, но может составлять трудности для формирования правильной логики работы сайта в целом.

Ресурсы динамичного сайта

Вопрос времени (момента относительно прихода посетителя) загрузки стилей, картинок, скриптов — компетенция и профессионализм разработчика. Если по логике области применения или спектра решаемых задач требуется сразу загрузить весь функционал, никаких усилий не требуется. При отработке события onload останется только запустить логику с какой-либо начальной точки.

Некоторые ресурсы (например, картинки товаров в магазине) сразу не определены по ассортименту (содержанию) и могут динамически изменяться. Приход посетителя должен сопровождаться отслеживанием момента времени: обработчик входа посетителя JavaScript (onload) и image (load) — процессы, разнесенные во времени.

Совершенно не обязательно включать в функционал обработчика входа все, что «может пригодиться». Картинки (image), звуки (sound) и другие объемные ресурсы всегда можно загрузить в момент использования или предусмотреть логику предварительной подгрузки в ходе диалога с посетителем.

Живой и динамичный сайт

Трудно представить создание современного динамичного сайта без применения JavaScript и onload. Function GoPage() — это не просто определение состояния браузера и перерасчет координат элементов страницы (в примере выше).

Function GoPage — это вызов сервера «InitXML( …» для принятия важных решений и «продолжения отношений».

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

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

Если рассматривать onload как приход посетителя, то ситуация переходит из события страницы в событие «взаимодействия» между посетителем сайта (постоянным клиентом), в их отношения в течение времени.

…что означает «окончание загрузки страницы»? • А хотите, я расскажу вам…

Предисловие

Прежде чем автотест начнёт выполнять какие-либо действия с элементами на странице веб-приложения, ему нужно сначала дождаться окончания загрузки страницы. Всякий порядочный инструмент автоматизации пытается это сделать, и Selenium не исключение. Он тоже пытается. Но у него не всегда получается. Впрочем, не только у него, другие инструменты автоматизации тоже “косячат”. И сейчас я постараюсь объяснить, почему это происходит.

Что означает с технической точки зрения “окончание загрузки страницы”?

Чтобы ответить на этот вопрос, надо сначала определить, что такое “страница”?

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

Начало

Вернёмся лет на пятнадцать назад. Internet Explorer 5. Netscape Navigator 4. HTML 3.2.

В то время веб-приложения, действительно, состояли из отдельных “страниц”. У каждой страницы был уникальный адрес. Указываешь в браузере адрес – загружается страница с этим адресом.

Каждая страница содержала размеченный текст в формате HTML. Кроме этого на страницу могли подгружаться картинки и описания стилей (вместе они назывались “дополнительные ресурсы”).

Вот так выглядел сайт Yahoo в 1996 году

После того, как браузер загружал текст страницы в формате HTML, он его анализировал и отрисовывал в соответствии с разметкой. Как только завершалась отрисовка – страница показывалась пользователю, и это можно считать “окончанием загрузки страницы”.

Да, после этого ещё продолжали подгружаться картинки, иногда достаточно долго, потому что интернет в те времена работал не слишком шустро. Страница при этом могла перерисовываться – вставленная картинка куда-нибудь сдвигала остальные элементы.

Поэтому стали выделять два различных момента “окончания загрузки”

• когда загрузилось и отрисовалось основное содержимое страницы,
• когда догрузились и отрисовались все картинки и описания стилей.

В процессе обработки страницы браузер меняет специальное свойство document.readyState, которое как раз и содержит информацию о текущем этапе загрузки:

• loading означает, что страница ещё загружается,
• interactive означает, что основное содержимое страницы загрузилось и отрисовалось, пользователь уже может с ней взаимодействовать, но ещё продолжается загрузка дополнительных ресурсов,
• complete означает, что все дополнительные ресурсы тоже загружены.

Так вот, Selenium использует именно это свойство document.readyState для определения момента окончания загрузки страницы.

Я предполагаю, что большинство других инструментов делает то же самое.

Как именно Selenium анализирует свойство document.readyState – я расскажу в следующей статье. А сейчас давайте продолжим путешествие в прошлое, потому что это только в самом начале было всё так хорошо и понятно.

JavaScript

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

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

Первым применением новой технологии стало “украшательство”. В веб-приложениях появились анимированные кнопки, переливающийся всеми цветами радуги текст, бегущая строка, выпадающие меню. В общем, всё сверкало и крутилось.

Это учебный сайт, где учат делать как раз такие украшательства

Поначалу это нововведение практически не повлияло на понятие “страницы”. Теперь на страницу помимо картинок мог ещё подгружаться программный код, который её менял. Но менял не очень сильно.

Зато поменялся ответ на вопрос, когда можно считать, что страница “полностью загружена”.

Программный код условно делился на две категории: тот, который выполняется “до загрузки страницы” и “после загрузки страницы”.

Считалось, что код, который находится в заголовке страницы (тег script, находящийся внутри тега head), выполняется до загрузки страницы. Кроме того, если в теге body указан обработчик события onLoad, который выполняет какой-то код – этот код тоже считается выполняющимся до загрузки страницы.

То есть правило стало таким: страница считается полностью загруженной тогда, когда браузер загрузил её текст, отрисовал, а также выполнил программный код, находящийся в заголовке и в обработчике события onLoad.

Но инструменты по прежнему ориентировались на изменение свойства document.readyState, потому что эта стратегия всё ещё успешно работала.

AJAX

А потом случилась вторая революция. Сложность кода на языке JavaScript постепенно возрастала, и в какой-то момент появилась идея динамического формирования страниц. То есть с сервера загружается не сразу готовая страница, а только шаблон, основа, а также JavaScript-код, который должен сформировать окончательное содержимое страницы. Этот код запускается уже после того, как основа страницы отрисовалась, подгружает оставшееся содержимое и достраивает страницу. Эта технология получила название AJAX.

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

Действительно, представьте себе, что вам нужно показать пользователю какие-то данные, которые достаточно долго формируются, причём становятся доступны постепенно (например, результаты каких-нибудь вычислений).

Вместо того, чтобы на сервере долго ждать, пока все данные станут доступны, можно быстро отгрузить в браузер страницу, в котором вместо данных находится “заглушка”, надпись о том, что данные будут доступны чуть позже.

Страница загружается, отрисовывается, пользователь её видит… Загрузка страницы завершена? Ну, вроде бы да. Но ведь данных на ней ещё нет? И это верно.

А в это время на странице работает программный код, который периодически отправляет запросы на сервер, чтобы узнать, не появились ли данные для отображения. И как только получает ответ – “дорисовывает” эти данные на станице. Причём может быть не все сразу, а по частям, по мере поступления.

Можете посмотреть на живой пример такой динамически обновляющейся страницы

И вот тут в полный рост встаёт проблема с определением того, когда можно считать, что “страница загрузилась полностью”. Ведь код, подгружающий данные, выполняется уже “после загрузки страницы” с точки зрения браузера.

Инструмент автоматизации (в том числе и Selenium) может определить момент, когда шаблон отрисовался, браузер выполнил код, который должен быть выполнен “до загрузки страницы”.

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

Да и нужно ли дожидаться? Может быть для конкретного теста эти данные вовсе и не нужны, может быть ему надо просто пройти по какой-то ссылке, которая есть уже в шаблоне страницы. Тогда было бы просто глупо ждать, пока загрузятся все данные.

Selenium и не ждёт. Для него по прежнему сигналом об окончании загрузки страницы является изменение свойства document.readyState. Всё, что происходит позже – это уже ваши проблемы. Пишите свой собственный код, который реализует нужные вам ожидания, потому что никто кроме вас не знает, когда можно считать завершённой подгрузку этих дополнительных данных.

AJAX, продолжение

А потом кто-то придумал вообще не загружать новые страницы, а вместо этого обновлять существующие.

Усложним пример, описанный в предыдущей части.

Предположим, что нужно показать пользователю много данных. Разработчики подумали, как лучше это сделать, и решили реализовать постраничный вывод. Примерно так, как это можно увидеть в большинстве поисковых систем. Но не совсем так, а более хитро: когда пользователь кликает по ссылке, которая загружает “следующую страницу с данными”, на самом деле никакого перехода на другую страницу с точки зрения браузера не происходит. Вместо этого средствами JavaScript подгружается новый фрагмент данных и обновляется содержимое текущей страницы.

Вот живой пример такой таблицы

Мало этого обмана – иногда при таком мнимом переходе ещё и адрес страницы меняется!

Примером такого рода является поисковая система Google. Содержимое другое, адрес другой, а с точки зрения браузера станица та же самая. Вот такой парадокс.

GWT, ExtJS, Angular и другие

А потом начался настоящий трэш и угар. В некоторых веб-приложениях страницы как таковые исчезли совсем.

Посмотрите, например, на GMail. Там постоянно открыта одна и та же “страница”, даже адрес не меняется. Переходите в другую папку – обновляется часть текущей “страницы”. Открываете письмо – это тоже происходит на той же самой “странице”. Начинаете писать новое письмо – открывается плавающий блок, даже не закрывается уже открытое письмо. Запускаете чат – и он тоже появляется в плавающем блоке на той же самой “странице”.

Что уж говорить про такие приложения, как, например, “рабочий стол”.

В этих случаях о “страницах” (и об окончании их загрузки) вообще говорить бессмысленно.

Подведём итог

Здесь я просто повторю то, что уже было сказано выше.

Selenium (и, я думаю, большинство других инструментов тоже) использует свойство document.readyState для определения момента окончания загрузки страницы.

Если ваше приложение продолжает обновлять содержимое уже после того, как свойство document.readyState приобрело значение complete – значит, вам нужны самодельные ожидания, которые будут проверять какие-то другие критерии “завершения загрузки”.

---

June 09
2015

Автор: Алексей Баранцев

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

---

Please enable JavaScript to view the comments powered by Disqus.

• Программирование на Python для тестировщиков
• Selenium: стартовый уровень
• Тестирование производительности (JMeter)
• Программирование на С# для тестировщиков
• Автоматизация функционального тестирования
• Тестирование веб-приложений 2.0
• Программирование на Java для тестировщиков
• Selenium WebDriver: полное руководство
• Организация автоматизированного тестирования
• Практикум по тест-дизайну 2.0

А ещё есть? Конечно!

Процесс загрузки страницы | Документация New Relic

В этом документе объясняется:

• Как загружается веб-страница
• Как мониторинг браузера измеряет время загрузки страницы, также известное как мониторинг реальных пользователей (RUM)

Совет

Это описание традиционного синхронного время загрузки страницы. Браузер также может отслеживать время асинхронной загрузки страницы.

Процесс загрузки страницы

Ниже приведены основные этапы загрузки большинства веб-страниц. Цифры 1-6 на схеме соответствуют пронумерованным шагам ниже.

Временная шкала загрузки страницы: Шаги, связанные с загрузкой веб-страницы. Диаграммы мониторинга браузера отображают следующие сегменты этого процесса: Сеть , Веб-приложение , Обработка DOM и Отображение страницы .

1. Загрузка страницы начинается, когда пользователь выбирает гиперссылку, отправляет форму или вводит URL-адрес в браузере. Это также называется начальным запросом или началом навигации . Действие пользователя отправляет запрос по сети на сервер веб-приложений.
2. Запрос поступает в приложение для обработки. (Запрос может занять некоторое время, прежде чем начнется обработка запроса. Это может быть результатом постановки запроса в очередь или другими факторами. )
3. Приложение завершает обработку и отправляет ответ в формате HTML обратно по сети на сервер пользователя. браузер. Это иногда называют ответом start или first byte .
4. (время до первого байта) Браузер пользователя начинает получать ответ HTML и начинает обрабатывать объектную модель документа или DOM .
5. DOM завершает загрузку; эта точка известна как DOM ready . Используя DOM, браузер пользователя начинает отображать страницу.
6. Страница завершает рендеринг в браузере пользователя, и срабатывает событие загрузки окна . (Для страниц, использующих асинхронную загрузку, некоторые элементы могут продолжать загружаться после того, как произойдет событие загрузки окна.)

Диаграммы времени загрузки страниц в мониторинге браузера

Мониторинг браузера фиксирует основные сегменты времени загрузки страниц на странице Сводка браузера и на странице Просмотров страниц. Если у вас включен мониторинг SPA, у вас будет доступ как к этой диаграмме, так и к диаграммам, относящимся к SPA. На диаграммах показаны:

• Сеть
• Время веб-приложения
• Обработка DOM
• Отображение страницы
• Другие сегменты, например, очередь запросов

Цвета диаграммы соответствуют цветам на диаграмме времени загрузки страницы.

one.newrelic.com > Браузер > (выберите приложение) > Сводка : Диаграмма времени загрузки отображается на странице Сводка и Просмотров страниц.

Способ, которым браузер собирает это время, зависит от способности браузера использовать API спецификации времени навигации. Вы можете добавить настраиваемые события времени загрузки страницы с помощью API агента браузера.

Вот описания действий, включенных в сегменты диаграммы времени загрузки браузера:

Время веб-приложения включает время, проведенное на сервере приложений. Это можно определить только в том случае, если инструменты браузера для определения времени загрузки страницы были предоставлены агентом APM.

Сетевой уровень включает время, затраченное на переадресацию, а также на запрос и получение HTML. Это не включает время на сервере или для статических активов.

Измерение сетевого времени начинается с первого щелчка по ссылке. Сетевое время включает DNS и может включать более одного поиска, если на вашем сайте есть перенаправления, TCP (включая брандмауэр, если вы не настроили мониторинг времени очереди запросов) и время соединения SSL.

• Если вы настроили мониторинг времени очереди запросов, то сетевое время не включает время очереди запросов, которое идет после заголовка X-Request.

• Если вы не настроили мониторинг времени очереди запросов, то сетевое время действительно включает все время очереди запросов.

  API спецификации синхронизации навигации предоставляет подробную разбивку сетевого времени. (Для старых браузеров таймер запускается по событию «перед выгрузкой».)

  Для приложений, которые были развернуты с использованием метода копирования/вставки, браузер включает веб-приложение и время ожидания в сетевом времени. Это связано с тем, что браузер использует агент на стороне сервера для передачи значений приложения агенту браузера посредством автоматической инъекции.

  Для получения дополнительной информации о том, как это внутреннее время разбивается с точки зрения браузера, используйте страницу Session traces . Трассировка сеанса сообщает обо всех доступных событиях, связанных с сетью, поэтому вы можете видеть в каждом конкретном случае, как браузер тратит время на поиск DNS и другие сетевые события.

  Важно

  Даже при настроенной очереди запросов настройка внешнего сервера все еще может влиять на время сети. Это связано с тем, что интерфейсный сервер не добавляет заголовок времени ожидания в очереди до тех пор, пока он фактически не примет и не обработает запрос. Если интерфейсный сервер настроен таким образом, что запросы начинают отставать и ставиться в очередь в сокете прослушивателя, который интерфейсный сервер использует для приема подключений, тогда вы увидите увеличение сетевого времени для мониторинга браузера. Заголовки времени ожидания в очереди никогда не могут учитывать отставание в этом сокете прослушивателя.

Обработка DOM — это время, необходимое для преобразования HTML в DOM и извлечения или выполнения синхронных сценариев. Если браузер начнет загружать изображения на этом этапе, время загрузки страницы будет отражать время загрузки изображения.

Слои обработки DOM и рендеринга страницы включают сетевое время для статических ресурсов (ресурсы, которые не извлекаются явным образом после загрузки страницы). Однако, если сценарий на странице динамически вставляет теги изображения и загружает изображения после завершения работы сервера или системы доставки контента (CDN), время загрузки страницы не может зафиксировать время загрузки изображения.

Фаза рендеринга страницы — это время между завершением DOM и событием загрузки окна. Этот этап измеряет обработку содержимого страницы на стороне браузера и часто включает время загрузки скриптов и статических ресурсов.

Очередь запросов будет отображаться на диаграмме времени загрузки, если ваша учетная запись связана с браузером и APM. В New Relic очередь запросов относится к времени между запросом, поступающим в ваши производственные системы, и его достижением вашим приложением. В зависимости от специфики вашей производственной инфраструктуры это время может включать фактическую очередь, в которую входят запросы, или оно может представлять другие функции, требующие времени (такие как балансировка нагрузки или задержка внутренней сети).

Запросы сервера приложений и транзакции браузера

Часто количество транзакций сервера приложений (запросов в минуту или об/мин ) превышает количество транзакций браузера (страниц в минуту или стр/мин ) для одного и того же приложения. Дополнительные сведения см. в процедурах устранения неполадок.

Выбросы

Независимо от того, насколько хорошо работает ваше приложение, будут некоторые медленные браузеры, платформы и сети, из-за которых ваше общее совокупное время отклика будет выглядеть медленнее. Чтобы свести к минимуму перекос, вызванный выбросами, время загрузки страницы фиксирует и масштабирует время отклика конечного пользователя, которое превышает значение параметра Apdex T в браузере более чем в 4,5 раза, до 4,5-кратного значения Apdex T или до 13,5 секунд, в зависимости от того, что больше. (Выбросы гистограммы обрезаются на 95%.)

Например, если порог Apdex T конечного пользователя вашего приложения составляет 8 секунд, это время отклика будет ограничено 36 секундами. Это сводит к минимуму влияние этого времени отклика на ваше приложение в целом, но по-прежнему обеспечивает учет «разочарованных» оценок Apdex.

Для мониторинга SPA выбросы обрабатываются по-другому. Когда продолжительность начальной загрузки страницы или изменения маршрута достигает 30 минут, это событие рассматривается как недопустимые данные и отбрасывается.

jQuery при загрузке страницы не работает

1 ответ на этот вопрос.

0 голосов

Связанные вопросы в JQuery

Это событие работает с элементами, связанными с … ПОДРОБНЕЕ

ответил 21 июня в JQuery по раджата • 7 440 баллов • 152 просмотра

• jquery

Привет @картик, Если ваш HTML-элемент CSS имеет следующую разметку переполнения, scrollTop будет … ПОДРОБНЕЕ

ответил 29 мая 2020 г. в JQuery по Нирой • 82 800 баллов • 8 406 просмотров

• HTML
• CSS
• JavaScript
• ларавель
• филиппинов

jQuery Timepicker может анализировать наиболее часто используемые … ПОДРОБНЕЕ

ответил 1 июня в JQuery по Эдурека • 13 640 баллов • 225 просмотров

• JavaScript
• HTML
• jquery
• хронометр

Используйте методы ajaxStart() и ajaxStop(). Во время работы… ПОДРОБНЕЕ

ответил 10 июня в JQuery по гаурав • 18 960 баллов • 449Просмотры

• jquery
• jquery-мобильный

Если вы не знали, Microsoft планирует … ПОДРОБНЕЕ

ответил 15 октября 2018 г. в IoT (Интернет вещей) по Энни97 • 2 160 баллов • 210 просмотров

• jquery
• нетто

Я предлагаю вам проверить 2 вещи Этот jquery.sparkline.js на самом деле …

ПОДРОБНЕЕ

ответил 9 ноября 2018 г. в Апач Спарк по Фрэнки • 9 830 баллов • 641 просмотр

• искра
• спарклайн
• jquery

Привет, jQuery — это быстрый и лаконичный JavaScript … ПОДРОБНЕЕ

ответил 14 февраля 2020 г. в JQuery по картик • 37 510 баллов • 367 просмотров

• HTML
• CSS
• JavaScript
• jquery
• угловой код

Привет Картик, Переменная, объявленная вне функции, имеет .