Answers.Body: <p>Seems to be the case that Craft won't attempt to resolve these <code>/cpresources/transforms/</code> 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.</p>
  
  <p>Solution in my case was to to set <code>'generateTransformsBeforePageLoad' =&gt; true,</code> in your Craft config array as mentioned <a href="https://craftcms.stackexchange.com/a/785/414">here</a></p>
  
  <p>After doing this, all transform URLs resolve and the page is properly cached.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-29T10:09:20.743Z
Answers.Text: Thanks for solving this, cmal! This is really helpful as I also want to set up PictureFill on a Craft install this week.
Answers.UserDisplayName: carlcs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-29T20:21:47.680Z
Answers.Text: 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.
Answers.UserDisplayName: Patrick Harrington
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-29T01:36:22.617Z
Answers.LastActivityDate: 2014-07-29T02:24:52.037Z
Answers.LastEditDate: 2017-04-13T12:50:59.930Z
Answers.UserDisplayName: cmal
Body: <p>I'm using <a href="http://scottjehl.github.io/picturefill/" rel="nofollow noreferrer">PictureFill</a> on a large page, containing many image transforms, that doesn't seem to be caching despite most of the page being wrapped in <code>{% cache %}</code> tags. When I view the page after several refreshes with Dev Mode enabled, the Profiling Summary Report is reporting <code>Total Queries</code> at 174, and the HTML source still contains many examples of image urls that contain something like <code>/cpresources/transforms/XX</code>.</p>
  
  <p>I read in <a href="https://craftcms.stackexchange.com/a/785/414">this answer</a> 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?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-07-28T22:58:19.307Z
Comments.Text: 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.
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-07-29T00:30:33.140Z
Comments.Text: 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?
Comments.UserDisplayName: cmal
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-07-29T00:40:02.447Z
Comments.Text: 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.
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-07-29T01:02:27.947Z
Comments.Text: 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.
Comments.UserDisplayName: cmal
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-07-29T01:07:39.110Z
Comments.Text: 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
Comments.UserDisplayName: cmal
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-07-29T01:21:37.970Z
Comments.Text: 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 <noscript> tag. I'm guessing that because these images are almost never requested, they will never be resolved, and as a result the cache will never be generated. Does that sound right?
Comments.UserDisplayName: cmal
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-07-29T01:22:46.850Z
Comments.Text: 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).
Comments.UserDisplayName: Patrick Harrington
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-07-29T01:25:59.170Z
Comments.Text: 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 <noscript>) remaining cpresources, and thus the page never being cached.
Comments.UserDisplayName: cmal
Tags: <cache><performance>
Title: Caching not working on page with asynchronously loaded asset transforms
ThreadText: # Caching not working on page with asynchronously loaded asset transforms
  
  (Asked by: username_0 on 2014-07-28)
  
  I'm using [PictureFill](http://scottjehl.github.io/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](https://craftcms.stackexchange.com/a/785/414) 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?
  
  **Tags:** cache, performance
  
  > **Comments:**
  > **username_1**: 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.  
  > **username_0**: Thanks, username_1. 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?  
  > **username_1**: 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.  
  > **username_0**: 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.  
  > **username_0**: 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  
  > **username_0**: 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 <noscript> tag. I'm guessing that because these images are almost never requested, they will never be resolved, and as a result the cache will never be generated. Does that sound right?  
  > **username_2**: 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).  
  > **username_0**: 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 <noscript>) remaining cpresources, and thus the page never being cached.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2014-07-29. Score: 12 | Accepted answer
  
  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](https://craftcms.stackexchange.com/a/785/414)
  
  After doing this, all transform URLs resolve and the page is properly cached.
  
  > **Comments:**
  > **username_3**: Thanks for solving this, username_0! This is really helpful as I also want to set up PictureFill on a Craft install this week.  
  > **username_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.  
  
  ---
  
  