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

CC BY-SA 3.0
2015-10-30T08:22:44.867Z
Amazing ! 
Without the cache: 
Time:   0.68351s
Memory: 17,065Kb
Total Queries: 51
j00lz
CC BY-SA 3.0
2015-10-30T08:27:35.907Z
that's the same comparison with the image commented out...
with it in:
Time:   1.59595s
Memory: 18,967Kb
Total Queries: 155
j00lz
CC BY-SA 3.0
2015-10-30T08:32:22.927Z
Wooot? Can you still cache it and tell us the time?
carlcs
CC BY-SA 3.0
2015-10-30T08:32:25.163Z
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
j00lz
CC BY-SA 3.0
2015-10-30T08:34:00.053Z
I'm amazed at how much overhead the |length requires !
j00lz
CC BY-SA 3.0
2015-10-30T08:35:01.340Z
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.
carlcs
CC BY-SA 3.0
2015-10-30T08:37:57.857Z
*"how much overhead the |length requires"* – you to give us an impression, are there many assets on the average entry?
carlcs
CC BY-SA 3.0
2015-10-30T08:55:45.327Z
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!
j00lz
CC BY-SA 3.0
2015-10-30T08:58:49.007Z
If you would need to know the number, you could request the IDs: `entry.slides.ids()|length`.
carlcs
CC BY-SA 3.0
2015-10-30T08:13:26.617Z
2015-10-30T08:13:26.617Z
2017-04-13T12:51:00.200Z
carlcs
<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>

CC BY-SA 3.0
2015-10-30T05:09:09.307Z
BTW. I took the cache tags out and commented the images for debugging to try find the problem
j00lz
<speed><optimization><query>
Optimizing pagespeed
# 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 entry in eDrops %}
                
                    {% if entry.slides|length %}
{#
                        {% set image = entry.slides.first() %}
#}
                         {{ entry.title }} >

{#
                        
#}
                        

                    {% else %}
                        {{ entry.title }}
                    {% endif %}

                    {% ifchildren %}
                        
                            {% children %}
                        
                    {% endifchildren %}

                
            {% endnav %}
        
    
{% 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?).
{% nav entry in eDrops %}

    {% cache globally using key 'eDrops-' ~ entry.id %}
        {% set image = entry.slides.first() %}

        {% if image %}
            
        {% 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`.  

---

