Mike Todd is the Chief Technology Officer at Roll20. He is avid about applying technology to make everyone’s life better, and has been with the combined company since 2004 when he first started with DriveThruRPG. In his personal life he enjoys TTRPGs, board games, card games, and video games.
In my last update, I spoke about stability and accountability. We’ve made some good strides in hardening our infrastructure, and though that work never truly ends, it has allowed us to shift more of our focus to another pillar of a great user experience: Performance.
“Performance” isn’t a single thing. It’s a combination of how quickly your game loads, how the experience holds up over a long session, how fast assets and sheets load, and how responsive everything feels in play. Recently, we’ve been digging into the “plumbing” of our various platforms to remove bottlenecks and streamline things.
And of course, performance work is never really “done,” it’s something that we dedicate time to constantly. I want to give a bit of a peek behind the curtain as to some of the performance-related projects we’re working on now.
VTT
Over the last year and a half, we rebuilt the VTT engine from the ground up, which has allowed us to more easily add features like new tabletop layers, Map Pins, and dozens of highly requested quality-of-life updates. But something that we haven’t addressed very transparently (until now) is that all of this also introduces more variables, which means more opportunities for something to affect your experience mid-game.
If you’ve ever noticed the VTT feeling a bit “heavy” after a few hours of play, you weren’t imagining it. We recently identified a memory leak triggered by opening character sheets multiple times. As our DOM (the “tree” of elements that makes up a webpage) has grown more complex over the years, this leak became more aggressive. Every time you opened/re-opened a sheet, a little bit of memory stayed “stuck,” eventually slowing down your entire browser. This issue was easier to resolve in newer sheets – like the new D&D sheet – and we put out a fix for that yesterday (Tuesday, April 7th). It also affects legacy sheets to a greater extent; there’s a 2x to 4x larger leak size for every new character opened on legacy sheets like the D&D 2014. That fix is more complicated, unfortunately, but we’re working on it now, and also tracking down some other memory leaks in the VTT so that we can fix them.
We have also started rolling out more general performance enhancements and tuning for the VTT engine itself. Our Software Development Director, Jeff, went into a great deep-dive of that in this post. We plan to make this the default experience for all users once we are confident that we haven’t missed any edge cases or bugs.
Another area we’ve focused on is the “critical path” of uploading assets into a game. We’ve conducted a deep-dive audit of our VTT upload pipeline and identified several instances of unnecessary computational work and sub-optimal data processing.
- JPG Uploads: We identified that we were needlessly turning JPGs into PNGs after upload. That took extra processing time that was ultimately unneeded, so last week we removed that step. This should help JPG uploads finish processing a lot faster.
- Firefox Fix (oopsie!): The above fix caused a user interface issue for Firefox, where even though the upload finished, the user interface didn’t ever acknowledge that. Soon after the above went live, we fixed this secondary issue. Mea culpa!
- Closer-to-Edge Uploads: Cloudflare is offering a beta feature that sends uploads to a POP (“Point of Presence”) that is closer to the person uploading the file. We enabled this on March 16th as well. While this won’t make a huge difference to many users, it could have a notable effect for people on slower connections and/or in more remote areas.
- More to Come: We’ve identified other issues in our upload pipeline that need various updates and fixes. This will take a bit more research, development work, and testing over the coming weeks and months. But it should result in uploads working faster and more smoothly as we find and address those issues.
The New D&D Sheet
The new D&D sheet is a massive leap forward from a technical and capabilities perspective, but it’s also a data-heavy beast.
Currently, our syncing logic is a bit “all or nothing.” When you make a change (even just ticking off a single hit point), the entire sheet’s data gets pushed up to the database and then “pulled down” to everyone else viewing that sheet. In engineering terms, it’s like re-sending an entire 300-page book just because you edited a typo on page 12.
It’s not optimal, and it’s one of the bigger reasons the sheet can sometimes feel “laggy” and why updates occasionally seem to vanish into the ether when two or more people have the same sheet open simultaneously (and it’s pretty common for a DM and the player to have a sheet open at the same time).
The team is currently rewriting how the sheet exports and ingests data to allow for more granular updates. Because of how this data is structured in Firebase (our data store), this requires a lot of finesse, so we are being extremely careful and putting this through extra-extensive testing to ensure nothing blows up. Once this lands, the sheet will load faster, feel more responsive, and handle multi-user editing much more gracefully.
DriveThruRPG
The modern DriveThruRPG site and its sister sites, like Dungeon Masters Guild, are built as Single Page Applications (SPAs). For those of you not familiar with that term, let me give a quick explanation. In a SPA, the browser loads the core application once, and then only fetches the specific data it needs as you click around. This is great for architecture, but it can cause a frustrating side effect known as “layout shift.”
You’ve likely experienced this at various sites: you go to click a link, but a split second later, a new component loads in, pushes the link down, and you end up clicking on the wrong thing. It’s annoying on a fast connection and a nightmare on a slow one.
To address this, the team is altering how we render and deliver pages. We’re moving toward a model where the server builds the page as a whole and sends it in a more “all at once” fashion, called Server Side rendering (SSR). This significantly reduces that “jumping” effect and makes the site feel much more solid and predictable as you browse for your next favorite PDF.
We’ve also been hard at work finding “problem queries” that make the database work too hard/long, and optimizing them. That’s something that is a smaller thing, but cumulatively adds up!
Demiplane
We’re also bringing this performance-first mindset to our newest family member, Demiplane. Peter Romenesko will be putting up a more in-depth post about that soon (and I’ll edit this post to add that link). But if you’re interested in the tl;dr version, the three big takeaways are:
- Frictionless Login: This isn’t exactly performance, but worthy of a shout-out. Now you don’t even have to see a Demiplane login screen, because it will use your Roll20 account by default. (With exceptions and workarounds for those who want to have separate accounts.)
- Snappier Interactions: In the current phase of work, we are optimizing in-sheet interactions to make them feel more immediate.
- Faster Load Times: The next phase of this work focuses on significantly reducing initial sheet load times.
What’s Next?
As we roll out these performance improvements, we are monitoring to ensure that these changes have a real, positive impact on you. Performance work is something that never really ends, but it’s also something that’s easy to ignore until it gets too bad. We know there’s still work to do, but we’re committed to making Roll20, DriveThruRPG, Demiplane, and Dungeon Scrawl the fastest, most reliable tools in your TTRPG kit.
Thanks for sticking with us, and as always, thanks for playing.
– Mike