<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>

CC BY-SA 3.0
2014-07-29T10:09:20.743Z
Thanks for solving this, cmal! This is really helpful as I also want to set up PictureFill on a Craft install this week.
carlcs
CC BY-SA 3.0
2014-07-29T20:21:47.680Z
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
CC BY-SA 3.0
2014-07-29T01:36:22.617Z
2014-07-29T02:24:52.037Z
2017-04-13T12:50:59.930Z
cmal
<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>

CC BY-SA 3.0
2014-07-28T22:58:19.307Z
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
CC BY-SA 3.0
2014-07-29T00:30:33.140Z
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
CC BY-SA 3.0
2014-07-29T00:40:02.447Z
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
CC BY-SA 3.0
2014-07-29T01:02:27.947Z
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
CC BY-SA 3.0
2014-07-29T01:07:39.110Z
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
CC BY-SA 3.0
2014-07-29T01:21:37.970Z
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?
cmal
CC BY-SA 3.0
2014-07-29T01:22:46.850Z
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
CC BY-SA 3.0
2014-07-29T01:25:59.170Z
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.
cmal
<cache><performance>
Caching not working on page with asynchronously loaded asset transforms
# 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, 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?  
> **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, cmal! 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.  

---

