9

I'm using PictureFill on a large page, containing many image transforms, that doesn't seem to be caching despite most of the page being wrapped in {% cache %} tags. When I view the page after several refreshes with Dev Mode enabled, the Profiling Summary Report is reporting Total Queries at 174, and the HTML source still contains many examples of image urls that contain something like /cpresources/transforms/XX.

I read in this answer that Craft won't cache a page with unresolved transforms, which might explain why this page isn't being cached. But then the question is, why aren't these transforms resolving?

Community
  • 1
cmal
  • 815
  • 4
  • 14
  • Are you getting any JS errors in your browser's console? If the transforms are throwing an error, it'll be logged in craft/storage/runtime/logs. With that many transforms running at once, it's highly possible PHP is running out of memory and/or time. – Brad Bell Jul 28 '14 at 22:58
  • Thanks, Brad. No javascript errors in the console, and my craft/storage/runtime/logs aren't reporting anything. Can you tell me where I could check to determine whether PHP is running out of memory/time? – cmal Jul 29 '14 at 00:30
  • If it's a PHP error, that would get logged in the same folder in a file called phperrors.log. If it's an Apache error, that's wherever your error log files are setup for. Probably worth checking the network tab in your browser and seeing what the response is for the transform AJAX request, too. – Brad Bell Jul 29 '14 at 00:40
  • No PHP errors, and no Apache Errors. Can you elaborate on the AJAX request? All of the image responses seem to return okay, but when the page loads the next time they all need to be made again. The viewed page source always contains a large number /cpresources/transforms/` urls. – cmal Jul 29 '14 at 01:02
  • I'm not sure it matters, but one thing that is unique about this situation is that most of the images on the page are not being loaded with the page, they are stored in a data-src attribute and PictureFill loads them asynchronously after the initial page load. Here's a snippet for reference: https://gist.github.com/cmalven/202027816afb2604e302 – cmal Jul 29 '14 at 01:07
  • Interesting, after reducing a bunch of images on the page, it seems that all of the images left with /cpresources/transforms/ urls are in the – cmal Jul 29 '14 at 01:21
  • Hmm - I've had performance issues on a site using picturefill as well. Very interesting to know if I have a similar issue (sitting at ~150 queries despite caching). – Patrick Harrington Jul 29 '14 at 01:22
  • Yep, that definitely seems to be the issue. I modified the fallback image inside of <noscript> to use the original upload (not a transform), and the page now loads much faster, suggesting that the cache was correctly generate. Now down to 12 queries (from over 174). Unfortunately, this only worked on one page of my site, other pages still have an issue with asynchronously loaded images (not in a – cmal Jul 29 '14 at 01:25

1 Answers1

12

Seems to be the case that Craft won't attempt to resolve these /cpresources/transforms/ URLs until the asset is actually requested, which can mess with a setup like PictureFill where there is no guarantee that the transformed assets will ever be loaded.

Solution in my case was to to set 'generateTransformsBeforePageLoad' => true, in your Craft config array as mentioned here

After doing this, all transform URLs resolve and the page is properly cached.

Community
  • 1
cmal
  • 815
  • 4
  • 14
  • Thanks for solving this, cmal! This is really helpful as I also want to set up PictureFill on a Craft install this week. – carlcs Jul 29 '14 at 10:09
  • 2
    Wow - I can confirm that if you're using Picturefill and image transforms, this makes a huge difference with regard to caching performance. Just dropped my page load from 150 queries down to 17. – Patrick Harrington Jul 29 '14 at 20:21