Timeline for Caching not working on page with asynchronously loaded asset transforms
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 13, 2017 at 12:51 | history | edited | CommunityBot |
replaced http://craftcms.stackexchange.com/ with https://craftcms.stackexchange.com/
|
|
| Jul 31, 2014 at 18:44 | vote | accept | cmal | ||
| Jul 29, 2014 at 17:06 | history | edited | cmal | CC BY-SA 3.0 |
Updated the original question and title to focus on PictureFill, as this is probably a better path towards people with a similar problem finding an answer.
|
| Jul 29, 2014 at 1:36 | answer | added | cmal | timeline score: 12 | |
| Jul 29, 2014 at 1:25 | comment | added | cmal |
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.
|
|
| Jul 29, 2014 at 1:22 | comment | added | Patrick Harrington | 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). | |
| Jul 29, 2014 at 1:21 | comment | added | cmal | 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? | |
| Jul 29, 2014 at 1:07 | comment | added | cmal |
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: gist.github.com/cmalven/202027816afb2604e302
|
|
| Jul 29, 2014 at 1:02 | comment | added | cmal | 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. | |
| Jul 29, 2014 at 0:40 | comment | added | Brad Bell♦ | 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. | |
| Jul 29, 2014 at 0:30 | comment | added | cmal | 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? | |
| Jul 28, 2014 at 22:58 | comment | added | Brad Bell♦ | 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. | |
| Jul 28, 2014 at 22:16 | history | edited | cmal | CC BY-SA 3.0 |
added 639 characters in body
|
| Jul 28, 2014 at 22:09 | history | asked | cmal | CC BY-SA 3.0 |