Когда браузеры начинают представлять частично переданный HTML?
Я имею продолжительный отчет и хочу показать ожидать-счетчик пользователю, в то время как он генерирует. Я уже сделал эту работу, но не уверено, что я делаю ее лучший или правильный путь.
Это использует ColdFusion, но это мог быть любой язык, который я предполагаю. В верхней части страницы у меня есть некоторый JavaScript (jQuery), который показывает ожидать-счетчик плюс существует documentReady обработчик, где я удаляю счетчик. Я сбрасываю вывод (если он имеет значение), и затем остальная часть работ кода над содержанием отчета. Это никогда не представляло счетчик, и я теоретизировал, что, даже при том, что я сбрасывал вещи на сервере, некоторая буферизация происходила по пути, и браузер никогда не видел код счетчика до слишком поздно. Так, я добавил цикл прямо, прежде чем я сбросил, которые выкладывают несколько сотен строк комментариев HTML. После подстройки количества строк, которые добились цели. Я предположил затем, что это - то, как другие сайты сделали это также.
Но: Сегодня, при наблюдении другой моей страницы, которая выкладывает линию за линией состояние продолжительного задания, мне что та страница сбросы после каждой строки и рендеринга браузера что инкрементно, как желаемый пришло в голову. Это не соответствует моему заключению сверху, и теперь я не знаю, каковы правила. Существует ли предсказуемый способ сделать это? Это варьируется на браузер?
РАЗЪЯСНЕНИЕ: Я ценю ответы, которые пытаются объяснить корректный способ сделать ожидать-счетчик, но я просто использую ожидать-счетчик в качестве примера для иллюстрирования моего реального вопроса: там надежные пути состоят в том, чтобы предсказать, когда браузеры начнут представлять HTML, поскольку он передается потоком им по сети? Это очевидно посредством наблюдения, что браузеры не ожидают / тега HTML для запуска работы. Этот вопрос не обязательно имеет какое-либо отношение к JavaScript. Например, та вторая страница, которую я описываю, что выставочным состоянием является чистый HTML.
4 ответа
--- Ответ после уточнения ---
Мой первоначальный ответ должен быть кому-то полезен (я надеюсь), но это не прямой ответ на вопрос, поэтому я отправлю другой ответ
Ответ на ваш повторный вопрос - «нет». В случае FF есть предопределенная начальная задержка рендеринга, но другие браузеры будут другими. Задержку рендеринга FF также можно настроить.
Используя FF в качестве примера, эти начальные 250 мсек - это время для FF найти по крайней мере некоторую полезную информацию перед попыткой первого рендеринга. Затем он периодически выполняет дополнительные рендеры по мере того, как узнает больше.
Вы не можете определить, когда браузер начал отображать HTML-документ.
--- Исходный ответ ---
Чтобы напрямую ответить на ваш вопрос, я считаю, что Firefox ожидает 250 мс, прежде чем действовать в соответствии с первыми полученными данными, но это можно изменить. Для других браузеров я не знаю.
Однако вы не хотите идти этим путем.
Когда jQuery будет готов творить чудеса, он сообщит вам об этом, запустив $ (document) .ready () . До этого любая попытка использовать jQuery потерпит неудачу. Другими словами, ваш счетчик не отображается, потому что jQuery еще не готов обработать этот запрос.
Рассмотрим следующий пример, где на экране показаны два заполнителя, и мы будем использовать jQuery, чтобы скрыть их.
<html>
<head>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.1/jquery.min.js"></script>
<script>
// We're not ready yet. This will fail.
$(".placeholder").hide();
$(document).ready(function(){
// This won't fail
$("#one").hide();
});
</script>
</head>
<body>
<div id="one" class="placeholder">Placeholder One</div>
<div id="two" class="placeholder">Placeholder Two</div>
</body>
</html>
Сначала может показаться, что $ ("# one"). Hide (); является избыточным, но это не так. $ (". Заполнитель").hide (); вызывается до того, как jQuery будет готов, поэтому он не имеет никакого эффекта, поэтому вы увидите, что отображается «Placeholder Two» (а не «Placeholder One»), если вы запустите разметку выше в веб-браузере. .
Теперь, когда у нас это есть, решение более крупной проблемы («правильный путь») - это AJAX.
- Загрузить базовую страницу, содержащую код счетчика. Убедитесь, что код для загрузки счетчика выполняется как часть
$ (document) .ready (). - Используйте функцию AJAX jQuery , чтобы получить нужный отчет.
- Когда он вернется, скройте счетчик, вставьте отчет на свою базовую страницу.
Удачи!
Я ожидаю, что это будет зависеть от браузера: некоторые начнут отображаться до того, как страница будет полностью получена; другие будут ждать весь HTML-файл перед запуском.
Замечу, что спецификация HTTP-ответа предоставляет заголовок «206 Partial Content», который может дать некоторую надежду на кроссбраузерное решение, на которое стоит обратить внимание.
Почти наверняка есть несколько способов вырезать это, но моя непосредственная идея состояла бы в том, чтобы доставить страницу-заглушку, а затем использовать ajax для извлечения и рендеринга фрагментов по запросу. например, многие большие сайты, кажется, изначально предоставляют минимальное представление, а затем, если вы прокрутите достаточно вниз, он запускает запрос ajax для получения дополнительных данных и добавления их на страницу. например: facebook, slashdot.
Я не могу представить, чтобы это было слишком сложно реализовать; даже при холодном сварке. Вы запускаете счетчик, когда запускаете запрос ajax, и останавливаете его, когда вызывается обратный вызов.
Если я правильно вас понял, вы хотите, чтобы "загрузочное" изображение отображалось во время загрузки страницы.
Что я делаю и что я считаю лучшим способом, так это добавляю div-тег вверху Вашей страницы, ближайший к теле-тегу, который содержит загружаемое изображение/текст. Вы можете разместить этот div-тег в другом месте с помощью какой-нибудь css.
Затем попросите Jquery удалить этот div при загрузке страницы. Вместо $(document).ready, как рекомендуют некоторые, я бы использовал $(window).load, так как он активируется при полной загрузке страницы, включая все кадры, объекты и изображения.
Se link here; http://4loc.wordpress.com/2009/04/28/documentready-vs-windowload/
Example;
<body>
<div id="loading" style="z-index:200; width:100%; height:40px; border-top:2px #D4D4D4 solid; background:#E8E8E8; color:#000; position:fixed; bottom:0; left:0;">
<div align="center">
<img src="load.gif" alt="Loading...">
</div>
</div>
<script type="text/javascript">
$(window).load(function() { $("#loading").remove(); });
</script>
[...]
...
Кроме встроенной задержки в Firefox, есть и другие области, которые заставляют браузер ждать перед рендерингом.
Когда html-страница отправляется в браузер, он сначала должен решить, где что находится, прежде чем отрисовывать экран. Например, таблицы печально известны тем, что вызывают задержки рендеринга. Для того чтобы нарисовать таблицу, браузеру необходимо вычислить размеры столбцов. Если вы используете проценты в качестве ширины столбцов или вообще не указываете их, то браузеру придется получить всю таблицу перед отрисовкой.
Однако если вы используете что-то вроде table-layout: fixed; css-атрибута, то браузер может просто считать первую строку и начать отрисовку по мере поступления данных.
Другие теги могут вызвать аналогичные проблемы. В принципе, в любой момент, когда браузеру нужно вычислить размер содержимого, он должен иметь все содержимое для отрисовки. Если вы можете дать ему подсказки заранее, используя элементы фиксированного размера (ширина/высота), то браузеру не нужно ничего вычислять, и он может отрисовывать элементы по мере их загрузки.
Как само собой разумеющееся правило, я никогда не позволяю браузеру определять что-либо. Вместо этого я задаю своим элементам фиксированные размеры. В результате сайты, над которыми я работаю, обычно имеют молниеносный рендеринг.