Speeding Up phpThumbOf in Evolution CMS

When a page feels slow even though the generated thumbnail itself is tiny, the real cost is usually not the download. It is the server work needed to find the source image, generate the thumbnail, write the cached file, and serve it back on the first request.

The original performance test behind this article showed a familiar pattern: the thumbnail downloaded quickly, but Time to First Byte stayed much higher than expected. In Evolution CMS projects this often points to phpThumbOf doing work on-demand for many images at once.

What to Check First

• Make sure thumbnails are really being cached in assets/cache/phpthumbof/ and that the web server can write to that folder.
• Check whether the page builds too many thumbnails at once in Ditto, DocLister, or another listing snippet.
• Measure disk I/O and source image size. Large originals can make thumbnail generation much slower than the final file size suggests.
• Confirm that your host is not doing extra work on every image request, such as antivirus scans or slow network storage.

Typical Optimizations

Keep thumbnail parameters predictable and let phpThumbOf reuse the same cached file whenever possible.

[[phpthumbof? &input=`[+image+]` &options=`w=100,h=75,zc=1`]]

For high-traffic listings, warm the cache before a campaign or indexing run. Even a simple crawl across important category and article pages can force the first generation to happen before real visitors arrive.

When to Move Beyond On-Demand Thumbnails

If a page outputs dozens of thumbnails and traffic is steady, consider pre-generating the most common sizes or storing already-prepared preview images in TVs. On-demand generation is convenient, but it should not be the bottleneck for a busy catalog or news archive.