Appearance
The fastest way to speed up an Omeka S site is rarely a bigger server — it is making sure pages serve small thumbnail images, enabling PHP OPcache, and putting a cache or CDN in front of public pages. Most slow Omeka sites are slow because browse pages are hauling full-resolution photographs and PHP is recompiling on every request. Fix those two things first and you will see the difference immediately.
Why is my Omeka S site slow?
Start by separating the two things that make a web page feel slow: how long the server takes to build the HTML, and how heavy the page is to download. Open your browser's developer tools, go to the Network tab, and load a browse page. You are looking for two numbers:
- The time-to-first-byte of the main HTML document (server work).
- The total transferred size of the page (asset weight).
For most beginners, the second number is the shock — a browse page of 24 items quietly pulling 24 full-size photographs at several megabytes each.
How do images affect performance?
Omeka S automatically creates derivative versions of each uploaded media file: a small thumbnail, a medium version, and keeps the large original. The problem is when a page uses the wrong one. A browse grid should use thumbnails; if a custom theme or misconfiguration pulls the large size, every page is dozens of megabytes.
Check that derivatives actually exist:
bash
# from your Omeka install, derivatives live under files/
ls files/large files/medium files/square
# square and medium should be present and small (KB, not MB)If derivatives are missing (common after a bulk import), regenerate them — the Easy Admin module or a derivative-rebuild task recreates them from the originals.
What is OPcache and why does it matter?
PHP normally reads, parses and compiles your code on every single request. OPcache keeps the compiled version in memory so that work happens once. It is the highest-value change you can make and costs nothing.
ini
; in php.ini — sensible starting values
opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=10000
opcache.validate_timestamps=1Restart PHP-FPM (or your web server), reload a page, and you should see server time drop. This single change often halves time-to-first-byte.
A small worked example
Suppose a local history society's site feels sluggish. Walk through it in order:
| Step | Action | Typical result |
|---|---|---|
| 1 | Network tab on browse page | Page weight 38 MB — red flag |
| 2 | Inspect an image URL | Theme served large, not square |
| 3 | Fix theme to use thumbnails | Page weight drops to ~1.5 MB |
| 4 | Enable OPcache | Server time halves |
| 5 | Add a CDN for assets | Repeat visits feel instant |
Notice that no hardware changed. Two configuration fixes did almost all the work.
Do I need caching or a CDN?
Omeka S does not cache full pages out of the box, so every anonymous visitor triggers fresh PHP and database work. For a public, read-heavy collection that is wasteful — the homepage is identical for everyone. Putting a reverse proxy (Varnish) or a CDN (Cloudflare and similar) in front of the site lets it serve cached HTML and assets to anonymous visitors without touching PHP at all. This is where a busy public site gets its biggest, most durable win. Logged-in editors bypass the cache so they always see fresh data.
How do I know a change actually helped?
Measure before and after, every time. A quick objective check:
bash
# time just the HTML response, repeated
curl -o /dev/null -s -w "ttfb: %{time_starttransfer}s total: %{time_total}s\n" \
https://yoursite.org/s/main/item?page=1Run it five times, note the median, make one change, run it again. If the numbers do not move, the change was not the bottleneck — undo it and look elsewhere. Changing several things at once hides which one mattered.
Key Takeaways
- Most Omeka S slowness is heavy images, not weak hardware.
- Make sure derivatives (thumbnail/medium) exist and that browse pages use them.
- Enable PHP OPcache — the biggest, cheapest server-time win.
- Omeka has no full-page cache; add Varnish or a CDN for public anonymous traffic.
- A modest 2 GB VPS handles thousands of items when configured well.
- Use the Network tab and
curl -wto measure objectively before and after each change. - Change one thing at a time so you know what actually helped.
Frequently Asked Questions
What is the single biggest cause of a slow Omeka S site?
Almost always large, un-derivative-served images. Omeka generates thumbnails and medium versions, but if those aren't being used — or originals are huge — pages haul full-resolution files. Confirm derivatives exist and that browse pages use them.
Do I need a powerful server to run Omeka S well?
Not for most collections. A modest VPS with 2 GB RAM and PHP OPcache enabled handles thousands of items comfortably. Performance problems are usually configuration, not hardware.
Should I turn on PHP OPcache?
Yes — it's the highest-value, lowest-effort win. OPcache stores compiled PHP in memory so the interpreter doesn't reparse files on every request. Enable it in php.ini and pages get noticeably faster instantly.
Will caching plugins help, and which ones?
Omeka S has no full-page cache by default. A reverse proxy like Varnish or a CDN in front of the site caches HTML and assets for anonymous visitors, which is where the biggest gains for public, read-heavy sites come from.
Why is my browse page slow even with few items?
Check how many properties your resource template renders and whether the page loads full-size media. A browse view that pulls medium or large images instead of thumbnails will crawl regardless of item count.
How do I measure Omeka S performance objectively?
Use your browser's network tab to see total page weight and slowest requests, then a tool like ab or curl -w to time the raw HTML response. Measure before and after each change so you know what actually helped.