4

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

  • BTW. I took the cache tags out and commented the images for debugging to try find the problem – j00lz Oct 30 '15 at 5:09
3

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 %}
            <img src="{{ image.getUrl('fitThumb') }}">
        {% else %}
            {{ entry.title }}
        {% endif %}
    {% endcache %}

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

{% endnav %}
| improve this answer | |
  • Amazing ! Without the cache: Time: 0.68351s Memory: 17,065Kb Total Queries: 51 – j00lz Oct 30 '15 at 8:22
  • that's the same comparison with the image commented out... with it in: Time: 1.59595s Memory: 18,967Kb Total Queries: 155 – j00lz Oct 30 '15 at 8:27
  • 1
    Wooot? Can you still cache it and tell us the time? – carlcs Oct 30 '15 at 8:32
  • 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 Oct 30 '15 at 8:32
  • 1
    If you would need to know the number, you could request the IDs: entry.slides.ids()|length. – carlcs Oct 30 '15 at 8:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.