

In that talk (and accompanying case study), Joe walks through the complete process with a realistic app. You’ll learn how to cache reactives, how to move data prep code out of your app, and a little applied psychology to help you app feel as fast as possible.įor a demo of the whole process of benchmarking, profiling, and optimising, I recommend watching Joe Cheng’s rstudio::conf(2019) keynote: Shiny in production: principles, best practices, and tools.

Profiling lets you see exactly where your code is spending its time, so you can focus your efforts where they’re most impactful.įinally, you’ll learn a handful of useful techniques to optimise your code, improving the performance where needed. Then you’ll learn how to profile your app using the profvis package to identify slow parts of your R code. This is the place to start, because it lets you figure you have a problem and helps measure the impact of any changes that you make. Next, you’ll learn how to benchmark your app, using the shinyloadtest package to simulate many people using your app at the same time. We’ll begin with a metaphor: thinking about a Shiny app like a restaurant. This is a feature of Shiny: it allows you to quickly prototype a proof of concept that works for you, before figuring out how to make it fast so many people can use it simultaneously.įortunately, it’s generally straightforward to get 10-100x performance with a few simple tweaks. A Shiny app can support thousands or tens of thousands of users, if developed the right way.īut most Shiny apps are quickly thrown together to solve a pressing analytic need, and typically begin life with poor performance.
