OnPageFinished занимает более 2 минут, когда URL-адрес доступен напрямую

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

Если я загружаю ту же страницу, коснувшись ссылки на странице на том же веб-сайте, onPageFinished() всегда приходит в течение 1-2 секунд (одно и то же подключение к Интернету, такие же точные условия).

Во всех случаях существует только один onPageStarted() и только один onPageFinished(). То есть никаких переадресаций не задействовано.

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

Чтобы лучше понять проблему, я предоставляю пример такой страницы:

http://mobile.nytimes.com/2013/07/19/world/middleeast/touring-refugee-camp-kerry-sees-mounting-syrian-suffering.html?from=homepage

Если вы заходите на эту страницу с домашней страницы веб-сайта, например, onPageFinished() поступает намного быстрее.

(сама страница, при обращении напрямую, получает onPageFinished() в течение 1-2 секунд!)

Что может объяснить это поведение?

Как устранить проблему, подобную этой?

Обновление 1: глядя на вывод LogCat, я заметил, что медленные (прямые) случаи характеризуются всплеском dalvikvm GC-операций сразу после onPageStarted():

07-18 21:22:33.876: D/dalvikvm(6298): GC_FOR_MALLOC freed 10371 objects / 495744 bytes in 54ms
07-18 21:22:34.016: D/dalvikvm(6298): GC_FOR_MALLOC freed 808 objects / 50824 bytes in 51ms
07-18 21:22:34.586: D/dalvikvm(6298): GC_FOR_MALLOC freed 1092 objects / 297328 bytes in 72ms
07-18 21:22:34.646: D/dalvikvm(6298): GC_EXTERNAL_ALLOC freed 49 objects / 2296 bytes in 59ms
07-18 21:22:36.526: I/global(6298): Default buffer size used in BufferedInputStream constructor. It would be better to be explicit if an 8k buffer is required.
07-18 21:22:36.626: D/dalvikvm(6298): GC_FOR_MALLOC freed 4687 objects / 513240 bytes in 86ms
07-18 21:22:36.626: I/dalvikvm-heap(6298): Grow heap (frag case) to 3.304MB for 131088-byte allocation
07-18 21:22:36.706: D/dalvikvm(6298): GC_FOR_MALLOC freed 928 objects / 53008 bytes in 69ms
07-18 21:22:36.766: D/dalvikvm(6298): GC_FOR_MALLOC freed 9 objects / 264 bytes in 61ms
07-18 21:22:36.766: I/dalvikvm-heap(6298): Grow heap (frag case) to 3.378MB for 131088-byte allocation
07-18 21:22:36.836: D/dalvikvm(6298): GC_FOR_MALLOC freed 0 objects / 0 bytes in 69ms
07-18 21:22:37.286: D/dalvikvm(6298): GC_FOR_MALLOC freed 547 objects / 98160 bytes in 73ms
07-18 21:22:37.286: I/dalvikvm-heap(6298): Grow heap (frag case) to 3.617MB for 262480-byte allocation
07-18 21:22:37.336: D/dalvikvm(6298): GC_FOR_MALLOC freed 175 objects / 8384 bytes in 46ms
07-18 21:22:37.706: D/dalvikvm(6298): GC_FOR_MALLOC freed 340 objects / 183688 bytes in 78ms
07-18 21:22:37.706: I/dalvikvm-heap(6298): Grow heap (frag case) to 3.994MB for 527244-byte allocation
07-18 21:22:37.776: D/dalvikvm(6298): GC_FOR_MALLOC freed 104 objects / 4560 bytes in 69ms
07-18 21:22:38.006: D/dalvikvm(164): GC_EXPLICIT freed 21550 objects / 1176488 bytes in 137ms
07-18 21:22:38.286: D/dalvikvm(6298): GC_FOR_MALLOC freed 227 objects / 299888 bytes in 50ms
07-18 21:22:38.286: I/dalvikvm-heap(6298): Grow heap (frag case) to 4.135MB for 444555-byte allocation
07-18 21:22:38.326: D/dalvikvm(6298): GC_FOR_MALLOC freed 1 objects / 16 bytes in 41ms
07-18 21:22:38.376: D/dalvikvm(6298): GC_FOR_MALLOC freed 352 objects / 687432 bytes in 36ms
07-18 21:22:38.376: I/dalvikvm-heap(6298): Grow heap (frag case) to 4.330MB for 592732-byte allocation
07-18 21:22:38.416: D/dalvikvm(6298): GC_FOR_MALLOC freed 2 objects / 104 bytes in 44ms
07-18 21:22:38.456: D/dalvikvm(6298): GC_FOR_MALLOC freed 4 objects / 96 bytes in 33ms
07-18 21:22:38.456: I/dalvikvm-heap(6298): Grow heap (frag case) to 4.612MB for 296374-byte allocation
07-18 21:22:38.496: D/dalvikvm(6298): GC_FOR_MALLOC freed 0 objects / 0 bytes in 41ms
07-18 21:22:38.536: D/dalvikvm(6298): GC_FOR_MALLOC freed 162 objects / 599848 bytes in 29ms
07-18 21:22:38.536: I/dalvikvm-heap(6298): Grow heap (frag case) to 5.170MB for 1185448-byte allocation
07-18 21:22:38.576: D/dalvikvm(6298): GC_FOR_MALLOC freed 0 objects / 0 bytes in 40ms
07-18 21:22:38.626: D/dalvikvm(6298): GC_FOR_MALLOC freed 7 objects / 1185616 bytes in 35ms
07-18 21:22:38.626: I/dalvikvm-heap(6298): Grow heap (frag case) to 5.443MB for 878616-byte allocation
07-18 21:22:38.676: D/dalvikvm(6298): GC_FOR_MALLOC freed 0 objects / 0 bytes in 42ms

Что это значит? Это проблема на веб-сайте? или в моем коде?

Обновление 2: это не только onPageFinished(), которое задерживается при прямом доступе к URL, но и WebChromClient.onProgressChanged()! Он всегда зависает с отметкой 89%, а затем пропускает до 100% сразу после получения onPageFinished(). Что-то странное происходит. Почему?

Может ли это быть преднамеренное поведение веб-сайта?

Если у вас возникает соблазн ответить "да", почему он этого не делает, обращаясь непосредственно к той же странице с помощью другого браузера (например, Firefox или Chrome)?

Если это не намеренное поведение этого конкретного сайта (т.е. ошибка в моем коде), почему это не происходит с другими веб-сайтами?

Ответ 1

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

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