Answers.Body: <p>Not sure how you implemented the <code>cache</code> tags, but I would recommend to cache each "eDrops" entry individually.</p>
  
  <p>I also took out <code>{% if entry.slides|length %}</code>. Testing if <code>entry.slides.first()</code> returns anything is all you need. In order to make the length filter work, Craft internally applys <code>find()</code> to the criteria model behind <code>entry.slides</code>. This means you (unintentionally) added an additional database query (besides <code>first()</code>, which you need anyways).</p>
  
  <p>Keep in mind, that assets are elements in Craft and relationship queries take their time (→ also explained in the Matrix field example here: <a href="https://craftcms.stackexchange.com/q/59/125">What are the most common template performance gotchas to avoid?</a>).</p>
  
  <pre><code>{% nav entry in eDrops %}
  
      {% cache globally using key 'eDrops-' ~ entry.id %}
          {% set image = entry.slides.first() %}
  
          {% if image %}
              &lt;img src="{{ image.getUrl('fitThumb') }}"&gt;
          {% else %}
              {{ entry.title }}
          {% endif %}
      {% endcache %}
  
      {% ifchildren %}
          {% children %}
      {% endifchildren %}
  
  {% endnav %}
  </code></pre>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-30T08:22:44.867Z
Answers.Text: Amazing ! 
  Without the cache: 
  Time:   0.68351s
  Memory: 17,065Kb
  Total Queries: 51
Answers.UserDisplayName: j00lz
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-30T08:27:35.907Z
Answers.Text: that's the same comparison with the image commented out...
  with it in:
  Time:   1.59595s
  Memory: 18,967Kb
  Total Queries: 155
Answers.UserDisplayName: j00lz
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-30T08:32:22.927Z
Answers.Text: Wooot? Can you still cache it and tell us the time?
Answers.UserDisplayName: carlcs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-30T08:32:25.163Z
Answers.Text: Caching the whole nav section Time:   0.14703s
  Memory: 8,775Kb
  Total Queries: 12
  
  and caching as you recommended:
  Time:   0.61642s
  Memory: 11,633Kb
  Total Queries: 50
Answers.UserDisplayName: j00lz
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-30T08:34:00.053Z
Answers.Text: I'm amazed at how much overhead the |length requires !
Answers.UserDisplayName: j00lz
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-30T08:35:01.340Z
Answers.Text: Well, you could do both, individual entries and the complete list. So you're not totally uncached after invalidation. But the gains are marginally in this case.
Answers.UserDisplayName: carlcs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-30T08:37:57.857Z
Answers.Text: *"how much overhead the |length requires"* – you to give us an impression, are there many assets on the average entry?
Answers.UserDisplayName: carlcs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-30T08:55:45.327Z
Answers.Text: indeed there are 100s of hi-res images on each one.... I thought that entry.slides|length would just return the length of the array ie. number of assets... which would be low computation cost compared to whatever it is doing!
Answers.UserDisplayName: j00lz
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-30T08:58:49.007Z
Answers.Text: If you would need to know the number, you could request the IDs: `entry.slides.ids()|length`.
Answers.UserDisplayName: carlcs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-10-30T08:13:26.617Z
Answers.LastActivityDate: 2015-10-30T08:13:26.617Z
Answers.LastEditDate: 2017-04-13T12:51:00.200Z
Answers.UserDisplayName: carlcs
Body: <p>I'm not sure what is the cause for this page rendering so slow.
  I thought it was the image transforms but I've removed them and still it's really slow to render.</p>
  
  <p>Page in question: <a href="http://dharmaavenue.net/e-drops" rel="nofollow">http://dharmaavenue.net/e-drops</a></p>
  
  <p>From the profiling report: </p>
  
  <p>Time:   64.61081s</p>
  
  <p>Memory: 461,289Kb</p>
  
  <p>Total Queries: 52</p>
  
  <p>As you can see it's just a simple nav menu.
  Here is the code:</p>
  
  <pre><code>{% block content %}
  
      {% set eDrops = craft.entries.section('eDrops') %}
  
      &lt;nav id="linksBrowser" class= "ladder tree"&gt;
          &lt;ul&gt;
              {% nav entry in eDrops %}
                  &lt;li&gt;
                      {% if entry.slides|length %}
  {#
                          {% set image = entry.slides.first() %}
  #}
                          &lt;a href="{{ entry.url }}"&gt; {{ entry.title }} &gt;
  
  {#
                          &lt;img src="{{ image.getUrl('fitThumb') }}"
                                  width= "{{ image.getWidth('fitThumb') }}"
                                  height= "{{ image.getHeight('fitThumb') }}"/&gt;
  #}
                          &lt;/a&gt;
  
                      {% else %}
                          &lt;span class="linkAnchor"&gt;{{ entry.title }}&lt;/span&gt;
                      {% endif %}
  
                      {% ifchildren %}
                          &lt;ul&gt;
                              {% children %}
                          &lt;/ul&gt;
                      {% endifchildren %}
  
                  &lt;/li&gt;
              {% endnav %}
          &lt;/ul&gt;
      &lt;/nav&gt;
  {% endblock %}
  </code></pre>
  
  <p>The entries are basically individual gallerys with many images in the slides field. I'm guessing that all the details of these are being fetched unecessarily, and that stopping this from happenign will solve my problem. </p>
  
  <p>If anyone can help me with this it would be most greatful :)</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-10-30T05:09:09.307Z
Comments.Text: BTW. I took the cache tags out and commented the images for debugging to try find the problem
Comments.UserDisplayName: j00lz
Tags: <speed><optimization><query>
Title: Optimizing pagespeed
ThreadText: # Optimizing pagespeed
  
  (Asked by: username_0 on 2015-10-30)
  
  I'm not sure what is the cause for this page rendering so slow.
  I thought it was the image transforms but I've removed them and still it's really slow to render.
  
  Page in question: <http://dharmaavenue.net/e-drops>
  
  From the profiling report:
  
  Time: 64.61081s
  
  Memory: 461,289Kb
  
  Total Queries: 52
  
  As you can see it's just a simple nav menu.
  Here is the code:
  
  ```
  {% block content %}
  
      {% set eDrops = craft.entries.section('eDrops') %}
  
      <nav id="linksBrowser" class= "ladder tree">
          <ul>
              {% nav entry in eDrops %}
                  <li>
                      {% if entry.slides|length %}
  {#
                          {% set image = entry.slides.first() %}
  #}
                          <a href="{{ entry.url }}"> {{ entry.title }} >
  
  {#
                          <img src="{{ image.getUrl('fitThumb') }}"
                                  width= "{{ image.getWidth('fitThumb') }}"
                                  height= "{{ image.getHeight('fitThumb') }}"/>
  #}
                          </a>
  
                      {% else %}
                          <span class="linkAnchor">{{ entry.title }}</span>
                      {% endif %}
  
                      {% ifchildren %}
                          <ul>
                              {% children %}
                          </ul>
                      {% endifchildren %}
  
                  </li>
              {% endnav %}
          </ul>
      </nav>
  {% endblock %}
  
  ```
  
  The entries are basically individual gallerys with many images in the slides field. I'm guessing that all the details of these are being fetched unecessarily, and that stopping this from happenign will solve my problem.
  
  If anyone can help me with this it would be most greatful :)
  
  **Tags:** speed, optimization, query
  
  > **Comments:**
  > **username_0**: BTW. I took the cache tags out and commented the images for debugging to try find the problem  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-10-30. Score: 3 | Accepted answer
  
  Not sure how you implemented the `cache` tags, but I would recommend to cache each "eDrops" entry individually.
  
  I also took out `{% if entry.slides|length %}`. Testing if `entry.slides.first()` returns anything is all you need. In order to make the length filter work, Craft internally applys `find()` to the criteria model behind `entry.slides`. This means you (unintentionally) added an additional database query (besides `first()`, which you need anyways).
  
  Keep in mind, that assets are elements in Craft and relationship queries take their time (→ also explained in the Matrix field example here: [What are the most common template performance gotchas to avoid?](https://craftcms.stackexchange.com/q/59/125)).
  
  ```
  {% nav entry in eDrops %}
  
      {% cache globally using key 'eDrops-' ~ entry.id %}
          {% set image = entry.slides.first() %}
  
          {% if image %}
              <img src="{{ image.getUrl('fitThumb') }}">
          {% else %}
              {{ entry.title }}
          {% endif %}
      {% endcache %}
  
      {% ifchildren %}
          {% children %}
      {% endifchildren %}
  
  {% endnav %}
  
  ```
  
  > **Comments:**
  > **username_0**: Amazing !  Without the cache:  Time:   0.68351s Memory: 17,065Kb Total Queries: 51  
  > **username_0**: that's the same comparison with the image commented out... with it in: Time:   1.59595s Memory: 18,967Kb Total Queries: 155  
  > **username_1**: Wooot? Can you still cache it and tell us the time?  
  > **username_0**: Caching the whole nav section Time:   0.14703s Memory: 8,775Kb Total Queries: 12  and caching as you recommended: Time:   0.61642s Memory: 11,633Kb Total Queries: 50  
  > **username_0**: I'm amazed at how much overhead the |length requires !  
  > **username_1**: Well, you could do both, individual entries and the complete list. So you're not totally uncached after invalidation. But the gains are marginally in this case.  
  > **username_1**: *"how much overhead the |length requires"* – you to give us an impression, are there many assets on the average entry?  
  > **username_0**: indeed there are 100s of hi-res images on each one.... I thought that entry.slides|length would just return the length of the array ie. number of assets... which would be low computation cost compared to whatever it is doing!  
  > **username_1**: If you would need to know the number, you could request the IDs: `entry.slides.ids()|length`.  
  
  ---
  
  