Is using 250+ custom fields on a page okay or is there a better way?

• simon_stekler

• March 4, 2021 at 10:07 pm

I’m building a site for a client with ACF, but there’s so much content on their homepage that it’s going to require around 250+ fields. Headlines, paragraphs, one-liners, images, icons, featured blog posts with a custom field for each, all that jazz.

I’m wondering if this is fine and still “best practice”, or what better alternative would you recommend when dealing with long sites that would require a lot of DB queries.

Caching will set up, but I’m still wondering what’s your go-to solution in these cases?

• John Huebner

• March 5, 2021 at 2:42 am

250+ fields sounds like there might be better ways to do what you want to do, but it would hard to be specific.

But one example. You mention that you’re going to have “Featured Blog Posts”. I would not create a box for choosing what blog posts to show. I would create a field group for blog posts that had a true/false field to set each blog post as featured or not. Then I would add code to the template to show blog posts that were set to featured using some criteria like the most recent 3 or 5 posts or whatever. I would probably also modify the admin list of posts and add a column to show if each post is featured or not to make it easy for the client to find the ones that are featured and edit them to change it.

As far as the rest goes, I would likely use Flexible Content for a lot of it and create layouts that meet the needs of their design. In fact, the “Featured Blog Posts” would likely be one of these layouts to let them choose some things about what “Featued Posts” to show. Or even, if the situation warranted, make it something that can be used for more than just featured posts, allowing them to adjust the content to suit their needs because with a little mortification it could be used for any realtionshp like “Related Posts”, “Related Pages”, etc.

• simon_stekler

• March 5, 2021 at 4:06 am

Thanks! Makes sense.

Would using flexible content actually reduce the number of database queries? Or is this advice coming from the user-experience and developer-experience standpoint rather than a performance oriented one?

• John Huebner

• March 5, 2021 at 4:48 am

When a post is set up WP does (or should) a single query to get and cache all of the postmeta fields for the post. These queries are based on the Post ID which is an indexed column in the DB. The number of queries should not be increased by the number of fields unless there is something else going on.

Additional fields will increase the time it takes to do this one query but that time should not effect a single query more than a few milliseconds depending on what kind of content is being returned. It is possible, but it would be an extreme case. For an example of something that could effect performance here think about a page with 250 WYSIWYG fields with several paragraphs of content in every one of those fields. Let’s say that fields average of 1000 characters that equates to 250 X 1000 = 250,000 characters being returned by the DB and this can mean anywhere from 250K to almost 1MB of UTF8 data. Of course this is an exaggeration to make a point.

There are things in ACF that will increase the number of queries, but this has to do with the formatting of the returned values. For example returning an array from image fields and galleries. Or returning post objects from relationship type fields.