<p>I don't think eager loading will help in this case because you're trying to eager load fields with only a single relationship (asset). It's not the n+1 query problem eager loading is meant to solve.</p>

<p>If you had an asset field with multiple assets selected, you would see some benefit. But even then, if there are only a few assets, the small penalty of eager loading might not outweigh the small cost of queries for a few assets.</p>

<p>Bigger gains would come from <a href="https://docs.craftcms.com/v3/dev/eager-loading-elements.html#eager-loading-nested-sets-of-elements" rel="nofollow noreferrer">nested relationships</a>. For example, a set of related entries each with an asset for a thumbnail image.</p>

<pre><code>{% do craft.app.elements.eagerLoadElements(
    className(entry),
    [entry],
    ['entriesField.image1']
) %}

{% for item in entry.entriesField %}
    {% set image = item.image1[0] ?? null %}
    {% if image %}
        {{ image.url }}
    {% endif %}
{% endfor %}
</code></pre>

<p>Also, it might be worth noting that in your testing, it matters what data you actually use.</p>

<p>In my test, this produced 19 queries:</p>

<pre><code>{% set asset = entry.headerImage.one() %}
{{ asset.title }}
</code></pre>

<p>But this produced 23 queries:</p>

<pre><code>{% set asset = entry.headerImage.one() %}
{{ asset.url }}
</code></pre>

CC BY-SA 4.0
2018-10-10T07:53:31.487Z
2018-10-10T07:53:31.487Z
Alex Roper
<p>Using this snippet returns me 38 queries on my homepage without the Eager Beaver plugin.</p>

<pre><code>{% do craft.app.elements.eagerLoadElements(
    className(entry),
    [entry],
    ['headerImage', 'image1', 'image2']
) %}
</code></pre>

<p>Without the above loading all three images with <code>.one()</code> gives me 33 queries.</p>

<p>Is this expected behavior or am I doing something wrong?</p>

CC BY-SA 4.0
2018-10-03T13:54:39.430Z
I'm not fully up to speed with Craft 3, but I don't understand why you are using the Twig do tag here in combination with that eagerLoadElements function. Have you taken a look at the Craft 3 documentation about eagerLoading?
https://docs.craftcms.com/v3/dev/eager-loading-elements.html#app
That has some great examples and explanation on how to do eager loading in Twig.
Tom De Smet
CC BY-SA 4.0
2018-10-04T10:14:45.593Z
I know how to do eager loading, but I wanted to take it to the next level.
Read more in this article about eager loading your entry.

https://nystudio107.com/blog/speed-up-your-craft-cms-templates-with-eager-loading.
Thaoms
CC BY-SA 4.0
2018-10-04T11:58:31.827Z
It would be helpful to get an answer to your question if you tell people that you're using a plugin. This isn't default Craft functionality nor syntax. It's the EagerBeaver plugin from NYStudio107.
Tom De Smet
CC BY-SA 4.0
2018-10-04T12:39:27.067Z
I'm not using the plugin, this out of the box Craft now, but I guess that before you had to use a plugin. He explains that later in the article.

Quote: Note that on Craft 3, you can do the exact same thing that the Eager Beaver plu­g­in does by using craft.app.elements.eagerLoadElements:
Thaoms
CC BY-SA 4.0
2018-10-04T13:44:33.023Z
So are you actually _using_ the `entry. headerImage`, etc. anywhere? If you do the query without eager loading, subsequent db queries are lazily evaluated, so they won't be triggered until you actually try to access a relation.
andrew.welch
CC BY-SA 4.0
2018-10-04T15:19:01.740Z
Alright, sorry Thaoms. Didn't know this. Guess I skipped some parts of the article :) I'll be quiet now and try to learn something new here :D
Tom De Smet
CC BY-SA 4.0
2018-10-05T12:58:24.230Z
@andrew.welch I did, test both headerImage.one() and headerImage[0]
Thaoms
CC BY-SA 4.0
2018-10-05T16:14:24.410Z
So it's potentially possible that if you only have a singleton of the thing, that the extra queries need to set up the eager loading will cause this; I'd have to do some profiling to know for sure. So the TL;DR is use eager loading when it benefits you (when you're looping through a number of things), and don't when it doesn't.
andrew.welch
<templating><craft3><image><eager-loading>
Eager loading on entry not reducing queries
# Eager loading on entry not reducing queries

(Asked by: username_0 on 2018-10-03)

Using this snippet returns me 38 queries on my homepage without the Eager Beaver plugin.
{% do craft.app.elements.eagerLoadElements(
    className(entry),
    [entry],
    ['headerImage', 'image1', 'image2']
) %}

Without the above loading all three images with .one() gives me 33 queries.
Is this expected behavior or am I doing something wrong?

**Tags:** templating, craft3, image, eager-loading
> **Comments:**
> **username_1**: I'm not fully up to speed with Craft 3, but I don't understand why you are using the Twig do tag here in combination with that eagerLoadElements function. Have you taken a look at the Craft 3 documentation about eagerLoading? https://docs.craftcms.com/v3/dev/eager-loading-elements.html#app That has some great examples and explanation on how to do eager loading in Twig.  
> **username_0**: I know how to do eager loading, but I wanted to take it to the next level. Read more in this article about eager loading your entry.  https://nystudio107.com/blog/speed-up-your-craft-cms-templates-with-eager-loading.  
> **username_1**: It would be helpful to get an answer to your question if you tell people that you're using a plugin. This isn't default Craft functionality nor syntax. It's the EagerBeaver plugin from NYStudio107.  
> **username_0**: I'm not using the plugin, this out of the box Craft now, but I guess that before you had to use a plugin. He explains that later in the article.  Quote: Note that on Craft 3, you can do the exact same thing that the Eager Beaver plu­g­in does by using craft.app.elements.eagerLoadElements:  
> **username_2**: So are you actually _using_ the `entry. headerImage`, etc. anywhere? If you do the query without eager loading, subsequent db queries are lazily evaluated, so they won't be triggered until you actually try to access a relation.  
> **username_1**: Alright, sorry Thaoms. Didn't know this. Guess I skipped some parts of the article :) I'll be quiet now and try to learn something new here :D  
> **username_0**: @andrew.welch I did, test both headerImage.one() and headerImage[0]  
> **username_2**: So it's potentially possible that if you only have a singleton of the thing, that the extra queries need to set up the eager loading will cause this; I'd have to do some profiling to know for sure. So the TL;DR is use eager loading when it benefits you (when you're looping through a number of things), and don't when it doesn't.  

---

## 1 answers

### Answer by username_3 on 2018-10-10. Score: 3 | Accepted answer

I don't think eager loading will help in this case because you're trying to eager load fields with only a single relationship (asset). It's not the n+1 query problem eager loading is meant to solve.
If you had an asset field with multiple assets selected, you would see some benefit. But even then, if there are only a few assets, the small penalty of eager loading might not outweigh the small cost of queries for a few assets.
Bigger gains would come from nested relationships. For example, a set of related entries each with an asset for a thumbnail image.
{% do craft.app.elements.eagerLoadElements(
    className(entry),
    [entry],
    ['entriesField.image1']
) %}

{% for item in entry.entriesField %}
    {% set image = item.image1[0] ?? null %}
    {% if image %}
        {{ image.url }}
    {% endif %}
{% endfor %}

Also, it might be worth noting that in your testing, it matters what data you actually use.
In my test, this produced 19 queries:
{% set asset = entry.headerImage.one() %}
{{ asset.title }}

But this produced 23 queries:
{% set asset = entry.headerImage.one() %}
{{ asset.url }}


---

