3

I'm working on a website for a music / artist agency. On the homepage we need al the artist entries. More than 200.

Each artist profile has an image, an image color extruder picker, some tags, relation, etc etc.

Without caching I have a lot of queries. But the page can render. If I enable cache, the server runs out of memory sometimes. And when I enable an entry, or edit an entry, the whole cache with the artist loop gets cleared.

This is my code.

{% block content %}
    {% cache for 1 week %}
        {% set cases = craft.entries({
            section: 'artist',
            order: 'title',
            limit: null
        }) %}

                {% for entry in cases %}
                    <article class="artist filter-{{ entry.title|first|lower }}">
                        {% set tags = entry.genre %}
                        {% set agent = entry.agent %}
                        {% set image = entry.introFoto.first() %}

                        ...
                        ... 
                        etc etc


                    </article>
                {% endfor %}
    {% endcache %}
{% endblock %}

So can I cache individual entries? Like so? When someone edits an entry, only that entry cache get cleared?

{% block content %}

        {% set cases = craft.entries({
            section: 'artist',
            order: 'title',
            limit: null
        }) %}

            {% for entry in cases %}
                {% cache for 1 week %}
                    <article class="artist filter-{{ entry.title|first|lower}}">
                        {% set tags = entry.genre %}
                        {% set agent = entry.agent %}
                        {% set image = entry.introFoto.first() %}

                        ...
                        ... 
                        etc etc


                    </article>
                {% endcache %}
            {% endfor %}

{% endblock %}
4

Sure. In my experience it's often better to cache individual entries, rather than whole pages, if the entries have a lot of relations to other elements. It's very resource intensive in Craft to figure out for instance if an image or entry relationship exists. And the more relations you have, the more frequent the cache would break.

The project I'm currently working on has a lot of different landing pages with entry items that have a ton of different images and relations. So I have A LOT of this going on for every single entry in a landing page:

{% if article.commentator | length %}
  {% if article.commentator.first().profileImage | length %}
    {% set listImage = article.commentator.first().profileImage.first() %}
    ...
  {% endif %}
{% endif %}

I found that when I cached the whole page, it would break often, resulting in a serious performance hit. I changed my code to cache individual entries. The difference in load of the page as a whole was small, but the actual impact in percieved performance was huge. In a positive way. :)

I also use the same generated HTML on a lot of different pages, so I also made the caching of these items globally. I create a key that is unique for the different options the block could have. The final cache tag looks something like this:

{% cache globally using key ("article-grid-item-" ~ article.id ~ "-" ~ gridType ~ "-" ~ modifier ~ "-" ~ craft.config.environment) for 3 hours unless craft.config.templateCacheDisabled %}
...
{% endcache %}

But the only way to figure out which would be better is to test it on your project. All builds are different, and as far as caching is concerned, there are no simple answers. ;)

And... I also wish P&T would make this easier/less resource consuming: {% if entry.image | length %} :)

|improve this answer|||||
  • And can you cache the whole page with all the small entry caches? Like wrapping a cache around the entry caches? – Johannes Lamers Dec 10 '14 at 12:31
  • 1
    Yes, as far as I can tell, it works just fine to wrap everything in a cache tag for the whole list. I chose not to do it on the project I'm working on, and I think that was because I tested and found that the "small" caches broke when the "big" one did. Kinda ruining the point. BUT, I've tested it again now and that doesn't seem to be the case, it works as it should. Don't know if I did something wrong, or if this is something that was fixed along the way. – André Elvan Dec 10 '14 at 13:00

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.