MacOS – Chrome delays first scroll

The difference is likely to do with the architecture and interprocess communication choices of each browser.

Modern web browsers render pages in separate processes. Apple has a framework called IOSurface that provides a streamlined way for one process to pass an image to another process. This framework was introduced in Mac OS X 10.6, aka Snow Leopard, for the latest iteration of QuickTime.

QuickTime uses IOSurface to offload movie decoding to separate processes. With no decoding to do, the QuickTime Player application is left dealing solely with the user interface and showing images provided by the decoding processes.

I suspect Safari has learned from QuickTime and is using the same techniques. Web pages are offloaded to other processes, rendered, and passed back.

Could Chrome and Firefox do the same thing, absolutely. The challenge is ensuring the thread dealing with the user responds quickly and is not delayed waiting for the rendering to update.

Chrome does use separate processes and appears to use IOSurface on the Mac; this bug talks about improving Chrome's use of IOSurface.

IOSurface is a public framework available to any Mac OS X 10.6+ application. However there is little documentation and it is Mac specific.

This is all conjecture.

I don't know any way to get the second frontmost application or window with AppleScript, apart from something like this:

delay 0.3 -- time to release modifier keys if the script is run with a shortcut
tell application "System Events"
    set p to process 1 where it is frontmost
    set visible of p to false
    delay 0.01
    key code 121 -- 121 = page down, 116 = page up
    set frontmost of p to true
end tell

It makes the hidden and activated windows flash though.

With browsers you could use window.scrollBy():

tell application "Safari" to tell document 1
    do JavaScript "window.scrollBy(0,(window.innerHeight-20))"
end tell

tell application "Google Chrome" to tell active tab of window 1
    execute javascript "window.scrollBy(0,(window.innerHeight-20))"
end tell

Another option would be to simulate pressing ⌃F4, page up or page down, and ⌃⇧F4 by for example using KeyRemap4MacBook:

<autogen>__KeyToKey__ KeyCode::CURSOR_UP, ModifierFlag::FN | ModifierFlag::CONTROL_L | ModifierFlag::NONE, KeyCode::F4, ModifierFlag::CONTROL_L, KeyCode::PAGEUP, KeyCode::F4, ModifierFlag::CONTROL_L | ModifierFlag::SHIFT_L</autogen>
<autogen>__KeyToKey__ KeyCode::CURSOR_DOWN, ModifierFlag::FN | ModifierFlag::CONTROL_L | ModifierFlag::NONE, KeyCode::F4, ModifierFlag::CONTROL_L, KeyCode::PAGEDOWN, KeyCode::F4, ModifierFlag::CONTROL_L | ModifierFlag::SHIFT_L</autogen>

It also causes a visual glitch, and ⌃F4 sometimes selects windows from hidden applications.