u/horejsek1

An update on Drive web photos: what we fixed, why not everyone felt it, and what's next

Hey r/ProtonDrive,

Michal, manager of the Drive web team here.

In May this year, we shared that photos and albums load faster on web (original post). Some of you saw a real difference. Others didn't, and you were right to call that out.

We took this feedback on. The first release was a step forward, but some key pieces were missing. We've been focused on fixing this. Here's what changed, why, and what's next.

SDK migration (the foundation)

The web client is now fully powered by our SDK. Photos was one of the last major sections to migrate. You won't see a visible difference from this alone, but it unblocked everything else.

Think of it as replumbing the house before renovating the kitchen: crypto and API logic are now separated from the photo UI. That separation matters because it lets us ship photo improvements faster, without fighting tightly coupled code.

This migration also cleared accumulated technical debt. We removed unnecessary API calls and batched others more efficiently. Before the migration, that wasn't really possible. UI and data logic were intertwined, and performance was capped by how React re-rendered the view. This was the main improvement in our first announcement, and for many users it made a noticeable difference.

Smarter loading (not just faster loading)

Making requests faster wasn't enough on its own. The app also needed to load the right things first.

Previously, we fetched thumbnails for everything near the viewport including a few rows above and below, but requests ran in parallel with no clear priority. The app could finish thumbnails quickly while you were still staring at spinners on the photos you were actually looking at.

Now, we load truly visible items first, then preload what's just off-screen for smooth scrolling. We also cancel queued thumbnail requests when you scroll away. Previously, if you jumped around quickly, previous work still sat in the queue and competed for bandwidth. Several jumps meant a growing backlog and slower loads. Requests that haven't started yet are now cleared when you move on.

Persistent thumbnail cache

We can optimize network and scheduling all we want, but the best load is no load at all.

We recently added an encrypted thumbnail cache in IndexedDB. It's overdue, and we're glad it's here. It stores roughly 500 recently viewed thumbnails. Enough to make return visits to the same albums feel instant if you've been browsing there recently.

To be upfront: a cold cache (first visit, new album, or cleared browser data) still has room to improve. That's a focus area for us. If things felt snappy only after you'd already been clicking around, the cache is likely why.

Firefox: a browser regression

Proton pushes browser crypto harder than most web apps, and that stress test exposed a bug in Firefox's crypto library. The photo improvements above were working, but on Firefox they were effectively masked by that underlying issue.

We mitigated by reducing parallel work in the meantime. The latest Firefox already addressed the root cause. More detail here: Why Drive web performance regressed on Firefox.

What's coming

HTTP/2 for thumbnail fetching

Every thumbnail is encrypted, so we fetch and decrypt each one ourselves rather than serving plain files from a CDN. Our storage API has historically been on HTTP/1.1, which creates a hard ceiling: browsers open only ~6 connections per domain, so loading many thumbnails in parallel hits a wall quickly.

HTTP/2 removes that bottleneck. We're working through one remaining blocker before we can switch. We hope to begin testing by end of Q3. We know "historical reasons" isn't satisfying, this is a real infrastructure constraint, not something we overlooked because photos didn't matter to us.

Better full-screen preloading

When you preview photos full-screen, we don't yet preload the next image as aggressively as we should. That means more spinners between photos than we'd like. This is already in progress; preview-modal preloading should land in the coming weeks.

More to come

Photos has always been one of the hardest Drive features to make fast. Encryption adds real cost that most cloud photo apps never pay. We're investing more in it now that the solid foundation is there.

Thanks for sticking with us, and for the honest feedback. It genuinely helped us prioritize and focus on the things that matter.

If you're still seeing slow photos after a hard refresh, let us know your browser, approximate library size, and whether it's first load or return visit. That helps us track down what's left.

The Drive Web team

reddit.com
u/horejsek1 — 3 days ago

Grid view is now available on public Drive links!

Hi, Michal here, engineering manager for the Drive web team.

As part of our continued efforts to improve the Proton Drive experience and make the product better, we've been completely rethinking and rebuilding the Drive file explorer with flexibility and adaptability in mind. This new foundation makes it much easier and faster for us to ship features that we have all wanted for a while that make the everyday experience smoother.

One of the first results: reused grid view on public pages (the page you land on when you open a publicly shared link). The new UI component made it simple to add it. It is not yet the photo view, yet it makes a huge difference if you're sharing a folder full of photos with someone. Instead of scrolling through a list, you get a proper visual overview at a glance. 

It's live now for everyone. Let us know what you think!

u/horejsek1 — 6 days ago

Why Drive Web performance regressed on Firefox?

Some of you may have noticed that Proton Drive feels sluggish on Firefox lately, we wanted to give you full transparency on what's going on and where things stand.

What's happening
After reports from users and internal testing, we traced the slowness to a performance regression introduced in Firefox 150. This isn't a Proton Drive bug, it's a browser-level change that affects how our app (and likely others) behaves. Chrome and Safari are unaffected.

How we found it
We bisected across Firefox versions to pinpoint exactly when it started, then went deeper into nightly builds to narrow it down to a specific Mozilla commit. We even compiled Firefox locally to test reverts and confirm the culprit. Once we had a solid case, we filed a Bugzilla report (Bug 2046401).

Working with Mozilla
This is where we want to give a genuine shoutout to the Mozilla team as they were incredibly responsive and collaborative throughout this process. We gave them a dedicated account to reproduce the issue, they dug in, confirmed multiple root causes, and got to work fast. One fix has already landed, with more on the way. These should all ship in future version of Firefox. If everything goes right, this should be uplifted in future Firefox 152 patches.

What we're doing in the meantime
We've shipped client-side mitigations to reduce the impact while waiting for the Firefox fix. The main one is thumbnail caching, so while the very first load may still feel slow, subsequent visits to Photos will be near-instant. This is rolling out progressively right now.

We'll update this post once the Firefox fixes are live. Thanks for your patience.

reddit.com
u/horejsek1 — 19 days ago