11

On certain websites, I noticed that if I access an inner page directly (i.e. not by touching a link from a different page on the same website), onPageFinished() takes forever (i.e. 2 minutes and more!) to arrive.

If I load that same page by touching a link in a page on the same website, onPageFinished() always arrives within 1-2 seconds (same Internet connection, same exact conditions).

In all cases there is only one onPageStarted() and only one onPageFinished(). That is, no redirects are involved.

Also, in both the direct (slow) and from-within-site (fast) access, the entire pages shows up as complete (visually). It is only the onPageStarted() that refuses to arrive for some reason (in the direct access).

To better understand the problem, I am providing an example of such page:

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

If you access this page from the website's homepage, for example, onPageFinished() arrives much faster.

(the homepage itself, when accessed directly, gets onPageFinished() within 1-2 seconds!)

What could explain this behavior?

How to troubleshoot a problem like this?

Update 1: Looking at the LogCat output I noticed that the slow (direct) cases are characterized by a burst of dalvikvm GC operations immediately after 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

What does this mean? Is this a problem in the website? or in my code?

Update 2: It's not only onPageFinished() that gets delayed on direct URL access, it's also WebChromClient.onProgressChanged()! It always freezes at the 89% mark, then skips to 100% right after onPageFinished() is received. Something weird is going on. Why?

Could this be intentional behavior of the website?

If you are tempted to answer "yes", why doesn't it do this when accessing directly that same page using a different browser (e.g. Firefox or Chrome)?

If this isn't intentional behavior of that specific website (i.e. bug in my code), why doesn't this happen with other websites?

WebViewer
  • 761
  • 7
  • 21

1 Answers1

0

This should be because the website must be loading too much resources in the inner pages.

Reason why it loads faster when accessing through links is, most of the webpages resources are shared and would have been cached by the webview through browse navigation.

nvn
  • 52
  • 3
  • 3
    Your theory would make sense if the first page loaded from that website which leads to that problematic page (e.g. homepage) would exhibit the same slowness. But it doesn't. It loads in 1-2 seconds! – WebViewer Jul 20 '13 at 00:50