Lightroom Classic is slow: find the bottleneck in your workflow
Import, browsing or developing: narrow down slow Lightroom steps and check storage, previews and the GPU one at a time.
When Lightroom Classic feels slow, the first thing you need is a bottleneck you can name. This article helps you pin the problem to one step of your work, test it in a comparable way and keep a useful fault log.
A slow import, stuttering image changes, sluggish sliders and a long AI process can have completely different causes. “Lightroom is slow” is therefore not yet enough for a diagnosis.
What exactly is taking too long?
Choose a small test set and note which step you are waiting on.
| What you see | Check first |
|---|---|
| Slow import | Card, card reader, connection and target drive |
| Delay when browsing | Previews and where they are stored |
| Sluggish sliders | GPU settings, drivers and background tasks |
| Long export | Number of images, resolution, edits and target drive |
Those are directions to look in, not firm diagnoses. Adobe’s performance notes provide the technical basis.
Keep the test conditions the same
Note the Lightroom version, the operating system and where the catalogue and the images live. Stop other demanding work. Wait until imports or preview builds have finished.
Repeat the same steps with the same photos. If you use different files, you may be comparing a simple development with elaborate masks and AI edits.
Change one thing at a time. Write down the result and keep a change if it helps in a way you can follow.
Check the route to the files
A fast computer can end up waiting on a slow or badly connected drive. So check the connection too, and any hub that sits in between.
Check the free space on the drives involved. The catalogue, the previews and temporary files all need room. Work with a backed-up test copy if you want to move storage locations.
Watch whether the delay only appears the first time an image opens, or also when you go back and forth between images straight away. That distinction is more useful for narrowing things down than an overall gut feeling about the computer.
Judge previews and the GPU separately
Prepared previews can help while culling. Which kind of preview makes sense depends on whether you need an overview or are checking details at a large size. Build them for your test set first and compare the same steps.
If the trouble is in the Develop module, check the GPU settings and the official notes for your hardware. “Always switch the GPU off” is no sensible blanket fix. Record whether a targeted comparison changes anything.
Treat denoising and other heavy calculations separately. How long they run says little about whether ordinary image changes stutter too.
If the behaviour started with an update
Check the known issues for your specific version. “Switching between these RAW files delays the display” is more useful for research than “everything hangs”.
Back up the catalogue before any major intervention. Leave catalogue or editing files you do not recognise alone, even if a forum post recommends deleting them.
At the end you should have either a bottleneck you can reproduce or a clear fault report: the step affected, the version, the hardware and the tests so far. With that you can look for support in a targeted way.
Measure import, culling and development separately
At the import, the card reader, the connection, the target disk and previews being built at the same time can all slow things down. While culling, what usually decides is whether suitable previews have already been calculated and where they sit. In the Develop module, RAW decoding, masks and GPU use come on top. At the export, the number of images, the output size, the edits and the target medium work together.
Measure one small, fixed number of images each time. A test without preview building answers a different question from a complete import run, and should be labelled accordingly.
Catalogue size is not automatically the cause
A large catalogue can work perfectly well. Before you split it, check the space used, the catalogue’s integrity, the previews, the drive connection and the specific delays. Several catalogues bring drawbacks of their own: searches and collections get spread out, and you have to maintain several backups.
A test log that helps
For each attempt, record the starting state, the setting you changed, the images used, the effect you saw and the way back. “GPU off was better” is hard to transfer without the step affected and the version. “Switching between the same 20 RAW files, the wait dropped reproducibly after change X” is a usable lead.
Undo changes that do nothing. Otherwise you are left with a system that differs from its starting configuration in many unknown ways.
Read on
- 10,000 wedding photos: a clear workflow through to delivery
- Moving photos to a new hard drive and finding them again in Lightroom
