Performance has been a huge focus for Confluence for the last several quarters, and one of our biggest foundational performance improvement projects has finally shipped to all users. This improvement is called Server Side Rendering (SSR), which speeds up initial page loads (visiting a Confluence page in a new tab) so that you can start reading and scrolling pages faster. SSR especially helps with slower networks and computers. Details about the improvements, how they work, and our next plans to continue improving performance of Confluence are covered below.
For Page Load performance one of the most important metrics for Confluence is First Meaningful Paint (FMP), which is how long it takes before users can start reading the page. SSR allows us to make huge strides in performance, with our slowest loads now twice as fast as before.
Most page loads | Slowest pages | |
FMP improvement over last 9 months | ~1.6x Faster | ~2x Faster |
Not only does SSR allow users to read the content faster, but it also ensures the Top Navigation and Left Navigation are shown immediately, rather than loading later. Plus, the Edit button is also now immediately clickable. Below you can see a simple side by side example of the two different loads, with the additional things circled in the SSR case.
New: Pages load Faster with SSR | Previous: Non-SSR Slower Page Loads |
Many features also load faster. In our testing, load times for these features are significantly faster:
Edit button loads 75% faster
Inline comments load 45% faster
Page tree loads 15% faster
Quick search loads 15% faster
We know that you want to move quickly and often you know you want to edit a page or add a comment even before you’ve read the page! So we made that faster, but will continue to improving them further.
Of course, there's a lot more that goes on behind the scenes! For the more technically inclined we're providing more details here.
User requests a URL from their computer
A Confluence SSR service checks permission and retrieves tenant information, and immediately starts streaming back data to help the browser preload Javascript
In the meantime another service (SSRS) renders the page on the cloud, processing user profile, permissions, and Javascript. Since this occurs very close to the data and executes on a powerful server, this occurs much faster than it would on the user’s computer
When done rendering, SSRS returns the page to you - this is not the full page, but the most important bits
You can start reading the page much sooner than before!
1. User requests a URL from their computer |
Depending on the type of page requested (Home, Editor, View) and other factors, it’s determined whether this page can be SSR-ed or not. If not, rendering defaults back to the old style. |
2. Confluence SSR service checks permission and retrieves tenant information. |
Authentication information has already been populated by the upstream services. We can quickly identify if we need to redirect the user to login. |
2.1 - Confluence SSR service figures out what Javascript files the client will need with the combination of route, locale setting, and frontend version. A preload hint is immediately sent back to the client so the browser can start downloading Javascript files. |
This relies on a in-memory cache that being populated by a previous render. More on this part later. The preload hint allows the client browser to start download and process Javascript, while waiting for the next step to occur. This pre-processing speeds up later steps significantly. |
3. Server-side Render as a Service (SSRS) renders the page on the cloud, processing user profile, permissions and Javascript. |
SSRS is a platform service shared by different Atlassian teams |
4. When done rendering, SSRS returns the page to the user - this is not the full page, but the most important bits. |
The rendered result is mostly HTML+CSS, with little to no JS. In addition to that, we serialize the Apollo cache state so when the React SPA renders we don’t need to query GraphQL again. |
5. User can start reading the page! |
Since there’s little to no JS at this point, only a few basic things are interactive on the page → In particular we’ve enabled the Edit button to be clickable. However, the most important interactivity is available - reading and scrolling the page. |
6. While user is reading, the React SPA code loads and is processed |
This step is the most dependent on user hardware, as the browser must process all of the downloaded JS, which is machine-dependent. But remember, at this point, the user can start reading the page already, which is the most important thing. |
7. After React SPA is fully loaded, there is a switchover from the SSR page to the SPA page, and things are interactive |
Users should see no difference here, as the React SPA should draw the exact same view as the SSR page. |
8. Other asynchronous items start to load, such as 3rd Party macros |
|
Delivering SSR is just the first (very large) step towards improving performance on Confluence - we are in no way done! Some of our next steps are:
Improving the SSR experience - in the side by side comparison you probably noticed the lack of Page Tree, and a few other elements. We’re working on improving this experience further, starting with the most commonly used items and moving down the list.
Improving loading time of the most used features - while we’ve sped some of them up a little, we’re targeting making all the commonly used features as fast as we’ve made the Edit button.
Improving your experience by focusing on a smoother loading process
Refactoring every piece of the product with a bent towards performance - in particular, delaying/lazy loading more code to later, so that the initial user experience becomes FAST.
We know how critical performance is, so we have the entire Confluence Cloud team dedicated to further improving Performance. As always, please feel free to lets us know any thoughts you have.
Dennis Lu
1 comment