Почему страницы сайтов «прыгают» вверх или остаются на месте при обновлении?

Question

[weranda]

Приветствую

Раньше не замечал, а если и замечал, то не придавал этому значение. Есть два типа страниц — "ровностоящие" и "прыгающие" (уж так я их назвал). Если страницу прокрутить к низу и обновить ее по кнопке F5, тогда "прыгающие" страницы во время обновления прокручиваются к верху и затем опускаются к исходному положению на момент ее обновления (заметно визуально и по скроллбару браузера), а "ровностоящие", как и сколько их не обновляй остаются на том же самом месте при обновлении.

Пример в GIF (на первой вкладке "ровностоящий" сайт, а на второй "прыгающий"):


Проверил около ста разных сайтов из закладок в браузерах Chrome и Opera. Примерно 10–15% по субъективным воспоминаниям (не считал) остаются на месте при обновлении страницы, остальные же нещадно прыгают. Не проследил никакой закономерности, и тут и там есть и простые сайты и с кучей скриптов, почти одинаковыми шаблонами и прочими совпадениями. Яркий пример "ровностоящей" страницы — https://github.com/blog/2496-commit-together-with-... Раз 100 обновлял, не прыгает, стоит как вкопанная.

Поведайте пожалуйста причины подобного поведения способы его достижения (чтобы страница не дергалась).

Comments

[Froggyweb]

Скорее всего грамотное кеширование

[Volodimir Babeshko]

Тут дело в особенностях вёрстки и кеширования. Простой пример - даже если сайт не подгружает ничего динамически, то он может все равно прыгать - например при некоторых реализациях решений проблемы вспышек текста с кастомными шрифтами без их кеширования (foit, fout) - тут механизм таков, высота блока авто, расчёт высоты текста ведётся со стандартным шрифтом и потом пересчитывается после подгрузки «правильного», но обычно так только с выключенным кешем в браузере бывает, аналогично блоки в которые идёт подгрузка контента, но ширина и высота не заданы жёстко (например требование дизайна или лень) и ещё при использовании в css calc - часто можно увидеть этот самый расчёт величины в виде поддергивания размера блока. Поэтому чтобы такого не было нужно или всему где можно задавать размер (не авто) и тестировать кеширование (стили, картинки, скрипты, шрифты), не на всех платформах (в частности не на всех мобильных) все работает так же красиво как на десктопе

Answer 1

[Александр Юдаков]

Вот так будет прыгать:

<p><img src=picture.jpg></p>
<p>Текст, текст, текст, текст, текст</p>

А вот так не будет:

<p><img src=picture2.jpg width=300 height=200></p>
<p>Текст, текст, текст, текст, текст</p>

Причина проста. Браузер всегда покажет абзац с текстом, не дожидаясь, пока загрузится картинка. Чтобы пользователь смог скоротать время за чтением текста.

Но тут у браузера возникает вопрос:
— А сколько свободного места оставлять под картинку?

Если мы размеры сразу укажем в html (300*200), браузер воспользуется нашей подсказкой и оставит 200 пикселей по высоте пустого места, чтобы потом там отобразить загруженную картинку.

Но если мы не укажем размеры картинки в html, у браузера этой информации не будет. Размер необходимого свободного места под картинку будет взят наобум. Следующий за картинкой текст будет нарисован на экране сразу после этого "наобум".

Уже потом, когда пользователь успеет прочитать половину текста, а браузер — загрузить картинку, размер нужного для картинки места будет пересчитан. При этом текст придется сдвинуть вниз.

Это и есть "прыжки" контента при загрузке страницы.

P.S. То же самое касается любого динамического контента, который подгружается скриптами после загрузки страницы. Размеры контейнеров под динамический контент нужно указывать сразу.

Comments

[wisgest]

Но тут у браузера возникает вопрос:
— А сколько свободного места оставлять под картинку?

— Вероятно, столько же сколько и в предыдущий раз, особенно если изображение сохранено в кэше.

Это и есть "прыжки" контента при загрузке страницы.

Вопрос не о первоначальной загрузке, а об обновлении уже загруженной.

[Александр Юдаков]

wisgest, какой кеш? Речь о первоначальной загрузке, либо об обновлении страницы.

И в том и в другом случае браузер отправит запрос на сервер — и даже если придет ответ 304 Not Modified, время будет потрачено на отправку запроса и получение ответа. В общем, кеш тут не сработает, даже если картинка там уже есть.

А чтобы вас не смущать, имя картинки во втором примере я поменял.

[wisgest]

Вопрос только об обновлении страницы и здесь поведение может отличаться от поведения при её первоначальном открытии. И не только может, но и отличается: при первоначальном открытии высота прокрутки, как правило, возрастает; при обновлении — зачастую может оставаться прежней или немного дёргаться, ползунок может стоять на месте как вкопанный, прыгать к началу или немного дёргаться, при этом в конце концов оказавшись на прежнем месте или немного смещённым, — зависит как от страницы так и от браузера. О чём и был вопрос. При этом кэширование действительно не при чём, но вполне разумным поведением для браузера является предполагать, что пока в процессе загрузки не доказано обратное, в качесстве начальных размеров и расположений элементов брать те, которые были в предыдущей реинкарнации.

[Александр Юдаков]

wisgest, ну и каша у вас в голове. Знания нужны, а не предположения.

https://www.webunlimited.com/web-designers-how-to-...

[wisgest]

Знания нужны, а не предположения.

https://www.webunlimited.com/web-designers-how-to-...

How To Lessen Page Load Content Shifting — Похоже, вы всё-таки не поняли вопрос. Никто не спрашивал, почему в процессе загрузки происходит перекомпоновка страницы. Это азбучные истины.
Вопрос, почему при повторном открытии, в частности при обновлении, эта перекомпоновка иногда отсутствует (это не совсем первоначальный вопрос, но ближе к нему; можно сказать, более общий).

Простой пример:

<img src="1.jpg">
<script>
console.log(document.images.item(0).clientHeight);
</script>
Hello!

Как видно, размеры изображения не заданы (истинная высота изображения — 1536).
Открыл, обновил. При обновлении всё оставалось на месте. В консоль Firefox вывело:

GET example.net/test/test.htm [HTTP/1.1 200 OK 1469мс]
24 test.htm:3:1
GET example.net/test/1.jpg [HTTP/1.1 200 OK 1891мс]
GET example.net/favicon.ico#-moz-resolution=16,16 [HTTP/1.1 200 OK 1062мс]
GET example.net/test/test.htm [HTTP/1.1 304 Not Modified 1281мс]
1536 test.htm:3:1
GET example.net/test/1.jpg [HTTP/1.1 304 Not Modified 375мс]

[fggavrilov]

Как избавиться от прыжков, не задавая фиксированые размеры картинок заранее?
Если картинки с шириной в процентах, высотой "авто", то придётся терпеть прыжки при загрузке и никак иначе?

[Александр Юдаков]

fggavrilov, можно посчитать физический размер картинки на сервере и записать эти сведения в data-атрибуты.

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

В скрипте, а не в css.

Пока скрипт первый раз не отработает, скрываем картинки, чтобы не было сдвига во время пересчёта размеров.

Пример решения похожей задачи:
https://detaligaz63.ru/catalog2/diagram120

Здесь расположение элементов на экране определяется на клиенте в скрипте. При этом Cumulative Layout Shift = 0