<p>I can't answer your question directly as I never got even close to 300 fields yet. But even with 50 fields I had some serious slowdowns, especially when getting related entries in form of assets and such. </p>

<p>I think you should definitely consider using the built in cache function to get good performance.</p>

<p>In regards to that field name / instructions problem you ran into, I can tell you that this is something I hope that gets changed in the future. I already made @Brandon Kelly aware of this problem and he probably has it on "the list".</p>

<p>.</p>

<p><em>Edit:</em></p>

<p>After thinking a bit more about this, I'd go with @Simon Kuran and believe that the number of fields have rather <s>negligible</s> moderate impact on your overall performance.</p>

<p>It's more about the numbers of DB queries and not that much about the amount of data they request.
Be careful with building and inquiring relationships in particular, as they can lead to many (unintentional) DB calls. But first and foremost: use caching. The <code>{% cache %}</code> tag is there for a reason! ;)</p>

CC BY-SA 3.0
2014-06-17T22:14:22.733Z
Are you saying with 50 fields _total_ on a site or 50 fields being parsed _at once_ for a template?
Simon Kuran
CC BY-SA 3.0
2014-06-17T22:25:37.353Z
50 fields total, but I thought they are queried anyways and have thereby an impact on performance. With `{% set entries = craft.entries.section('blabla').find() %}` you don't select the fields that are queried and put in that array. But please bear with me as I have no clue in fact and only wrote down the observations I made with my 50 fields and querying assets.
carlcs
CC BY-SA 3.0
2014-06-17T22:38:39.887Z
I'm definitely not certain either. Running `{{ dump(entries) }}` on your entries variable _does_ seem to get info on fields that are not associated with the section being queried. So maybe it does matter, but I would hope it would be a negligible change.
Simon Kuran
CC BY-SA 3.0
2014-06-17T22:42:26.100Z
This plugin was released today by Matt Stauffer... Not sure if it does what you want exactly (haven't tested it personally), but its purpose is to return only the fields specified: [Twig Prune for Craft CMS](https://github.com/mattstauffer/craftcms-prune/)
Lindsey D
CC BY-SA 3.0
2014-06-18T02:02:01.980Z
the prune plugin just filters out the entries fields after making all the queries, it will not speed anything up.
Luke Holder
CC BY-SA 3.0
2014-06-18T05:14:12.397Z
Good call Luke, it has no effect on the actual queries... ah well, nevermind.
Lindsey D
CC BY-SA 3.0
2014-06-17T22:10:45.583Z
2014-06-18T06:18:06.557Z
2014-06-18T06:18:06.557Z
carlcs
<p>I doubt any fields that are not being rendered have any influence on performance. I have have no worries about having a lot of "dormant" fields.</p>

CC BY-SA 3.0
2014-06-17T22:10:35.280Z
2014-06-17T22:10:35.280Z
Simon Kuran
<p>I know that on page load Craft makes multiple queries to get Fields. I have about 300 separate fields on a pretty large site. I know it's probably better to reuse fields when I can, but in many cases I can't rename fields or field instructions so I wouldn't be able to name them semantically for the user. </p>

<p>Is it OK to have this many fields on my site, or should I find another strategy to manage my large number of fields, many of which are very similar?</p>

CC BY-SA 3.0
2014-06-17T22:17:47.687Z
Just for clarification you're asking about fields in total on a site, not fields being rendered right?
Simon Kuran
CC BY-SA 3.0
2014-06-17T22:28:56.007Z
MUST be fields in total!! :D
carlcs
CC BY-SA 3.0
2014-06-17T23:02:14.523Z
Yep, fields in total on the site.
dfockler
<performance><field><queries>
Will having large numbers of Fields decrease site performance?
# Will having large numbers of Fields decrease site performance?

(Asked by: username_0 on 2014-06-17)

I know that on page load Craft makes multiple queries to get Fields. I have about 300 separate fields on a pretty large site. I know it's probably better to reuse fields when I can, but in many cases I can't rename fields or field instructions so I wouldn't be able to name them semantically for the user.

Is it OK to have this many fields on my site, or should I find another strategy to manage my large number of fields, many of which are very similar?

**Tags:** performance, field, queries
> **Comments:**
> **username_1**: Just for clarification you're asking about fields in total on a site, not fields being rendered right?  
> **username_2**: MUST be fields in total!! :D  
> **username_0**: Yep, fields in total on the site.  

---

## 2 answers

### Answer by username_2 on 2014-06-17. Score: 7

I can't answer your question directly as I never got even close to 300 fields yet. But even with 50 fields I had some serious slowdowns, especially when getting related entries in form of assets and such.

I think you should definitely consider using the built in cache function to get good performance.

In regards to that field name / instructions problem you ran into, I can tell you that this is something I hope that gets changed in the future. I already made @Brandon Kelly aware of this problem and he probably has it on "the list".

.

*Edit:*

After thinking a bit more about this, I'd go with @Simon Kuran and believe that the number of fields have rather ~~negligible~~ moderate impact on your overall performance.

It's more about the numbers of DB queries and not that much about the amount of data they request.
Be careful with building and inquiring relationships in particular, as they can lead to many (unintentional) DB calls. But first and foremost: use caching. The `{% cache %}` tag is there for a reason! ;)

> **Comments:**
> **username_1**: Are you saying with 50 fields _total_ on a site or 50 fields being parsed _at once_ for a template?  
> **username_2**: 50 fields total, but I thought they are queried anyways and have thereby an impact on performance. With `{% set entries = craft.entries.section('blabla').find() %}` you don't select the fields that are queried and put in that array. But please bear with me as I have no clue in fact and only wrote down the observations I made with my 50 fields and querying assets.  
> **username_1**: I'm definitely not certain either. Running `{{ dump(entries) }}` on your entries variable _does_ seem to get info on fields that are not associated with the section being queried. So maybe it does matter, but I would hope it would be a negligible change.  
> **username_3**: This plugin was released today by Matt Stauffer... Not sure if it does what you want exactly (haven't tested it personally), but its purpose is to return only the fields specified: [Twig Prune for Craft CMS](https://github.com/mattstauffer/craftcms-prune/)  
> **username_4**: the prune plugin just filters out the entries fields after making all the queries, it will not speed anything up.  
> **username_3**: Good call Luke, it has no effect on the actual queries... ah well, nevermind.  

---

### Answer by username_1 on 2014-06-17. Score: 1

I doubt any fields that are not being rendered have any influence on performance. I have have no worries about having a lot of "dormant" fields.


---

