What we got wrong about live wall lag in build 4

The obvious culprit

Our first instinct was network. We assumed the problem was bandwidth, or maybe a server somewhere choking under the load of a hundred guests uploading simultaneously. We built live photo wall for events where everything matters, and a frozen display is embarrassing. The wedding planner was kind about it, but the stakes were clear.

We pulled the logs. Network traffic looked fine. Server response times were normal. The refresh rate on the display was steady. So we dug deeper, and that's when we started asking the wrong questions. We asked: what's slow? Instead, we should have asked: what's *changing* on that screen, and how often?

The browser rendering surprise

The live wall is built to show new photos the moment they arrive. A guest uploads, and within seconds, their image appears on the big screen at the venue. That's the whole point. We refresh the photo grid every two seconds. Sounds reasonable.

But when you have a grid of thumbnails, and you're reloading the entire DOM every two seconds, and you're doing it on a tablet or TV screen running all day, the browser doesn't just fetch new images. It repaints the whole thing. Worse, if a guest uploads a video as well as photos (something we introduced for Occasion+), the browser has to handle video metadata alongside image rendering. Add in custom event frames, which overlay graphics, and you've got a cascade of layout recalculations happening faster than the display can keep up.

The network was fine. The server was fine. The browser was just exhausted.

The moderation queue lesson

We also overlooked something simpler. The live wall doesn't show every photo instantly. There's a moderation queue. Not because we're paranoid, but because hosts need control. Someone might upload a silly photo, or a blurry one, and the host should be able to review before it goes public on that big screen.

When we built that queue, we didn't think about the rendering cost of having it run in the background while the wall itself refreshes. Every time a new photo arrives, it has to check against the queue, render a decision, and update two separate interfaces. The host's moderation panel and the live display weren't communicating efficiently. Each was doing its own refresh cycle.

That gap between uploads and display wasn't just a network delay or a server bottleneck. It was the browser managing two parallel update streams and losing synchronisation.

How we fixed it, and what it cost

In build 4.1, we changed the refresh strategy entirely. Instead of repainting the whole grid every two seconds, we now update only the new photos. We batch uploads into smaller groups. We separate the moderation queue from the display rendering, so they're not competing for browser resources. And we added a setting in the host's control panel to adjust refresh speed based on the venue's network strength, though most venues don't need to touch it.

The fix wasn't clever. It was just more careful. We slowed down in some places and sped up in others. We tested it on a real iPad running all day at a corporate event, not just on our laptops for twenty minutes.

What surprised us was the trade-off we discovered. A faster refresh rate sounds better, but after about 1.5 seconds per refresh, you hit a point where the gains in immediacy don't matter anymore. A human eye watching a photo wall doesn't notice the difference between 1.5 seconds and 1 second. They do notice the difference between smooth and janky. So we optimised for smoothness instead of speed.

Why this matters for your event

If you're using the live wall at Occasion+ or Forever tier, you're probably running it on a display screen at your event, sometimes for hours. A wedding reception, a birthday party, a corporate gathering. That screen is not a laptop. It's likely a TV or tablet that might not have been restarted in days. Battery life matters. Heat matters. The longer the display runs smooth, the better the experience.

We learned that the live wall isn't just about moving photos fast. It's about sustaining a smooth experience under realistic pressure. Guests uploading in bursts. Videos mixed with photos. Custom frames and overlays. Moderation happening in the background. All of it happening at once.

The message we didn't expect

The wedding planner from Manchester sent us another message a week after build 4.1 rolled out. She'd used the updated live wall at another event. No lag. She didn't say much, just: 'It's smooth now. Thank you.' That was the entire note.

That message told us something important. When a feature works, nobody notices. When it breaks, everyone does. We'd spent two weeks chasing a problem that was really about paying attention to the small decisions that compound under load.