Sorry for this general question, i am building a large archive site with many (>1000) Events. Every Event has one or more Speaker. At the moment I am using two channels: "events" and "speakers" and work with relationships. My question is, is it better (in terms of performance) to work with categories for the speakers? The Website will have a long list with all speakers (>1000) and all events. Doing so, i have to query a lot of data.

John Doe

  • Event 1
  • Event 2

At the moment i am working in twig, but maybe I will change to work with json data, generated by the element api or maybe graphl. Whatever will be the most performative solution. So kind of a general question here: categories or channel for the speaker? And Should I stay with twig or change to json or graphql for quering that much data.

1 Answer 1


In terms of performance there's not much of a difference between a entries and categories. They're both elements so their database queries have similar structures and overheads. Differences in performance, if any, will be so small you won't ever notice them.

Much more important in terms of performance is that you make sure to properly optimize your queries. For the page that lists speakers with their corresponding events, make sure to use eager-loading for the events. This way, you can retrieve the speakers and their associated events in one query, instead of needing an additional query for each speaker. On top of that, make sure to cache the output of that page to avoid an expensive query for every page load.

Since performance isn't a factor for the decision between categories and entries in this case, I would just chose whatever makes more sense semantically. In this case, I'd say a list of speakers should be a section (channel). But it also depends on your further data structure requirements.

And Should I stay with twig or change to json or graphql for quering that much data.

This is unanswerable without knowing your requirements. If you don't need a dynamic frontend / SPA, stick with SSR (server-side rendering) using Twig templates. GraphQL and/or REST APIs coupled to a frontend introduces a lot of unnecessary overhead, I wouldn't go down that route if I didn't have a good reason to. Besides, SSR will always be faster than a single page application.

  • I have a further question for the scenario: with regard to performance: is it better to work with entries and relationships, so each speaker has a reversed relationship to an event. Or is it also a good idea to work with a matrix field inside an event. So that one event can have multiple speakers inside a matrix field. Without any (reversed) relationship. To display a list of speaker I have to query the matrix field than. Coming from wordpress i know that it is not a good idea to query repeater fields but how is it in craft?
    – buckdanny
    Nov 5, 2023 at 19:54
  • @buckdanny It's much better to use a simple relationships and not go through Matrix. I would use a single Entries field on the events where you can select one or multiple speakers. You can select multiple entries in a single field, so you don't need Matrix to have multiple speakers. This will allow you to easily query all speakers for a given event. And it's also trivial to find all events a given speaker is related to, see the Docs on Relations for details. Going through Matrix is also possible, but usually unnecessary.
    – MoritzLost
    Nov 6, 2023 at 10:09
  • 1
    thank you very much! I have overthought it a bit. I was also unsure because of the upcoming "entrification" of the Matrix fields. Vielen Dank lieber Moritz! Auch für den tollen Talk auf der dot all!
    – buckdanny
    Nov 14, 2023 at 19:59
  • @buckdanny Gern geschehen! :)
    – MoritzLost
    Nov 15, 2023 at 8:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.