FaceBook uses BigPipe in tandem with PJAX/Turbolinks-style partial rendering of the next URL the user navigates to. (IIRC they call those "partial reloads".) It then does a full reload every 10 requests (at least 4 years ago) to avoid memory consumption in the browser from growing too big.

Note this could also be implemented in a separate module, it is actually not specific or even related to BigPipe.

See:

CommentFileSizeAuthor
#6 Turbolinks quick PoC 60fps.mp42.05 MBWim Leers
Membership dollars fund testing for the Drupal project. Drupal Association Learn more

Comments

Wim Leers created an issue. See original summary.

Wim Leers’s picture

Category: Task » Feature request
Priority: Normal » Major
Wim Leers’s picture

Wim Leers’s picture

Issue summary: View changes
Wim Leers’s picture

Issue summary: View changes

More related reading:

Wim Leers’s picture

I created a very very very rough/hackish prototype. Still, it's showing promise already. This shows the difference in loading a page with and without turblinks, while switching between two nodes (note the changing URL in the address bar), with Turbolinks replacing the page's title and the main content.

Again, a very incomplete, very hackish implementation, but the visual difference is quite significant.

attiks’s picture

#6 Neat!

serg2’s picture

This looks impressive!

Is this with Turbolinks or the Turbograft port? What percentage of the normal page traffic is sent to the browser on the update? Most of it will be browser cached anyway but wondering if it is(in theory) sent/requested.

(This really highlights how much effect our broken toolbar has on the perceived speed of D8)

Wim Leers’s picture

This is with custom JS, building on top of Drupal's "AJAX system" and "behaviors" abstractions. The latter in particular allows us to avoid a big problem that many Rails apps have: they have JS doing jQuery.ready(…), which we've been warning against for many years now. Thanks to that, it's easy for us: we just need to detach behaviors on the old content, and attach it on the new content.

And since it's a super rough prototype, I can't actually answer the other questions yet.

Stay tuned for more to come in the next few weeks.

Wim Leers’s picture

Project: BigPipe » Turbolinks
Version: 8.x-1.x-dev »
Status: Postponed » Fixed

Good news! Acquia has given me time to push this forward. The result is an initial implementation that works in any theme, with Blocks/Panels/page manager/anything, and only sends regions that are changing between pages.

See https://www.drupal.org/project/turbolinks.

8.x-1.0-alpha1 release: https://www.drupal.org/node/2692267.

droplet’s picture

Version: » 8.x-1.x-dev

Congrats having fund to work on it :)

I have a quick look but it doesn't work out of box. ( empty responses )

Waiting for next releases!

Wim Leers’s picture

Did you apply the core patch? I bet you didn't, that would explain the broken responses :)

almaudoh’s picture

Core patch? Is there a core patch needed for this to work?

Edit: maybe that should be mentioned in the project page

almaudoh’s picture

Great!! So the visibility of HtmlRenderer::prepare() needs to be made public, and then it works. Turbolinks RefreshLess is sweet!! Wim++

Edit: Turbolinks sucks :(

Wim Leers’s picture

It's mentioned in alpha 1's release notes. I hope to be able to get rid of the core patch over time.

droplet’s picture

Great!! So the visibility of HtmlRenderer::prepare() needs to be made public, and then it works. Turbolinks is sweet!! Wim++

Cool. It does the tricks.

Wim Leers’s picture

Project: Turbolinks » RefreshLess
andypost’s picture

Naming things... Wim rocks!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.