Some ideas: - on the 'load' event - a timer X ms after the 'load' event. Or some combination of a timer an load event or first paint. Perhaps there are other heuristics as well
one way the current heuristic falls down is: - load "a.com" <-- does prewarm a process - press a link on "a.com" going to "b.com" <-- uses the prewarmed process - Go back (to "a.com" <--- does not prewarm a process - press a link on "a.com" for "c.com" <-- does not use a prewarmed process because one doesn't exist So we should take into account prewarming a process when using back/forward cache
(In reply to Saam Barati from comment #1) > one way the current heuristic falls down is: > - load "a.com" <-- does prewarm a process > - press a link on "a.com" going to "b.com" <-- uses the prewarmed process > - Go back (to "a.com" <--- does not prewarm a process > - press a link on "a.com" for "c.com" <-- does not use a prewarmed process > because one doesn't exist > > So we should take into account prewarming a process when using back/forward > cache actually, I'm off here. Maybe we don't need to do anything, since we do end up using a prewarmed process for "c.com", because "b.com" will prewarm a process
<rdar://problem/40094910>
I think we also need to merge navigation process prewarming with the process prewarming we already do to speed up launch.
(In reply to Geoffrey Garen from comment #4) > I think we also need to merge navigation process prewarming with the process > prewarming we already do to speed up launch. Merge in what sense? They both call the same codepath if that’s what you mean
> Merge in what sense? They both call the same codepath if that’s what you mean Yeah, I guess that's what I mean. :P