How do you deal with static content, like headers and footers?

I want a multiple page site, but don’t want to have to reload the headers and footers each time. I see there are resuable groups, but I don’t need them reloaded on every page.

You choose what pages you’d like to have them on. You need to insert reusable elements on every page.

That they’re reusable only indicate it’s possible to use them in multiple instances and to be able to alter all those instances through one single element.

Wouldn’t the performance better if these were static and cached? Seems ridiculous to reload them from the db on every page load.

Why don’t you build an SPA then? Have the visible header and footer, then use lots of hidden groups to represent the page contents and then show which one you need when you need it. The groups have a setting to shrink height when hidden, so you don’t end up with lots of whitespace.

1 Like

Good point. So the idea of DaveA is to build the entire site inside one page (the index ie), using show and hide groups. So the header and footer will be there all the time (never load again). We are using this method, working fine, and faster.

1 Like

In that case, doesn’t it load every single element and group on every page load? Seems even worse for performance.

Maybe I’m wrong, but data appears only when the Group is in a ‘show’ status. Overall, it take 1-2 seconds. Make your own test, and let me know, interesting point.

1 Like

There is only 1 page load, and then data is only accessed when it is shown as John Says. If there was a problem with this approach, I don’t think the whole SPA (Single Page Application) model would have taken off.

Do you own tests for your own use cases and work out which approach is best for your application and your own data model.

‘Seems’ and assumptions just don’t cut it I’m afraid :slight_smile:

2 Likes

No assumptions are being made, that’s why I started the thread. There really is no way to benchmark the performance.

Single Page is great for a small app that doesn’t have much database interaction. My concern, long term, is that if you get a good amount of traffic, each visitor is going to hammer the database for the content, unless it is cached.

There’s some tools outside to benchmark 10,000 users-transactions and more per seconds. Probably will have a look and give some feedback.

I have some experience from building a “native” mobile app that has to be done in this way. A few downsides of this SPA approach in Bubble:

  1. A user cannot save/share the URL of a specific page, since it’s all the same URL
  2. For a complex app, showing and hiding groups and having all workflows on one page is very hard to work with. Splitting into several pages, each responsible for a specific part of the app, makes it much easier to develop and maintain.

I did not see any performance issues.

1 Like