11

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?

  • Just for clarification you're asking about fields in total on a site, not fields being rendered right? – Simon Kuran Jun 17 '14 at 22:17
  • MUST be fields in total!! :D – carlcs Jun 17 '14 at 22:28
  • Yep, fields in total on the site. – dfockler Jun 17 '14 at 23:02
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! ;)

| improve this answer | |
  • Are you saying with 50 fields total on a site or 50 fields being parsed at once for a template? – Simon Kuran Jun 17 '14 at 22:14
  • 1
    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 Jun 17 '14 at 22:25
  • 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. – Simon Kuran Jun 17 '14 at 22:38
  • 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 – Lindsey D Jun 17 '14 at 22:42
  • 2
    the prune plugin just filters out the entries fields after making all the queries, it will not speed anything up. – Luke Holder Jun 18 '14 at 2:02
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.

| improve this answer | |

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.