<p>The performance aspect is difficult to answer. On every pageload, <a href="https://github.com/pixelandtonic/Craft-Release/blob/master/app/etc/templating/twigextensions/CraftTwigExtension.php#L466">Craft pulls <em>all</em> your global sets</a>, which can be a performance hit, especially if you have many huge, complex global sets with a lot of fields. Any Single used in place of a global could be pulled on a need-to-use basis, i.e. not on every page, although the extra call to the EntriesService would also come at a price. In any case, I wouldn't really worry too much about it one way or another.</p>

<p>As for other pros and cons – in my opinion, the pros would mainly be related to usability for your content editors. </p>

<p>Some people may find it easier to work with Singles because they live inside the Entries section of the CP, i.e. together with the bulk of the site's content. This is especially relevant if the global content in question is only displayed on certain pages, e.g. a tagline which is used in the homepage's header – in which case most content editors would look at the homepage single before anywhere else, I reckon.</p>

<p><a href="https://github.com/engram-design/ExpandedSingles">The Expanded Singles plugin</a> even lets you list your singles in the left sidebar, making it even easier for your editors to find them.</p>

<p>The most obvious con to using singles over globals would the fact that you would have to write Twig to pull the appropriate Single anytime you needed its data, whereas any global set will always be available everywhere – i.e. writing <code>{{ settings.tagline }}</code> is way simpler than <code>{{ craft.entries.section('mySettingsSingle')|length ? craft.entries.section('mySettingsSingle').first.tagline }}</code> or the like – unless, of course, you add the Single(s) to the global Twig context or implement a template variable, but that would require writing a custom plugin.</p>

<p>Also, there's no way to turn off URLs for singles – so any single you create in place of a global, you're going to have a "stray" URL in your system. Not a huge issue, but still.</p>

<p>Personally, I believe that opting for a Global Set is generally the Right Thing To Do if the content doesn't really have a place in any existing Single – rather than creating what is essentially "bucket" or container Singles to accommodate it. If your content editors find Globals hard to use/find, consider using the <a href="https://github.com/engram-design/CPNav">CP Nav plugin</a> to rename the "Globals" tab in the CP to something a little less technical – e.g. "Settings" or "Misc. content". Using CP Nav, you can even add tabs for specific Global Sets, with your own titles – in your case I'd consider creating a set called "Listing settings", adding the fields for the header image and introductory text to that set, and finally creating a tab in CP Nav called "Listings" or the like (or even "Wine Listing" if you want to get really specific), pointing to that particular Global Set. Personally, I think Globals – if done right – is actually better for usability than Singles pretending to be something they're not.</p>

CC BY-SA 3.0
2015-10-12T18:37:46.433Z
2015-10-12T18:37:46.433Z
Mats Mikkel Rummelhoff
<p>We are building a restaurant site that has a banner image and some introductory text on each page.  For pages that include content from a Channel, e.g. the wine list, we are using a Global to define the header image and the intro text, and then a "for loop" for the wine entries. </p>

<p>Are there any performance benefits to using a global versus a single?  Any other pros and cons related to those choices?</p>

<performance><globals><singles><content>
Globals versus Singles
# Globals versus Singles

(Asked by: username_0 on 2015-10-12)

We are building a restaurant site that has a banner image and some introductory text on each page. For pages that include content from a Channel, e.g. the wine list, we are using a Global to define the header image and the intro text, and then a "for loop" for the wine entries.

Are there any performance benefits to using a global versus a single? Any other pros and cons related to those choices?

**Tags:** performance, globals, singles, content

---

## 1 answers

### Answer by username_1 on 2015-10-12. Score: 8

The performance aspect is difficult to answer. On every pageload, [Craft pulls *all* your global sets](https://github.com/pixelandtonic/Craft-Release/blob/master/app/etc/templating/twigextensions/CraftTwigExtension.php#L466), which can be a performance hit, especially if you have many huge, complex global sets with a lot of fields. Any Single used in place of a global could be pulled on a need-to-use basis, i.e. not on every page, although the extra call to the EntriesService would also come at a price. In any case, I wouldn't really worry too much about it one way or another.

As for other pros and cons – in my opinion, the pros would mainly be related to usability for your content editors.

Some people may find it easier to work with Singles because they live inside the Entries section of the CP, i.e. together with the bulk of the site's content. This is especially relevant if the global content in question is only displayed on certain pages, e.g. a tagline which is used in the homepage's header – in which case most content editors would look at the homepage single before anywhere else, I reckon.

[The Expanded Singles plugin](https://github.com/engram-design/ExpandedSingles) even lets you list your singles in the left sidebar, making it even easier for your editors to find them.

The most obvious con to using singles over globals would the fact that you would have to write Twig to pull the appropriate Single anytime you needed its data, whereas any global set will always be available everywhere – i.e. writing `{{ settings.tagline }}` is way simpler than `{{ craft.entries.section('mySettingsSingle')|length ? craft.entries.section('mySettingsSingle').first.tagline }}` or the like – unless, of course, you add the Single(s) to the global Twig context or implement a template variable, but that would require writing a custom plugin.

Also, there's no way to turn off URLs for singles – so any single you create in place of a global, you're going to have a "stray" URL in your system. Not a huge issue, but still.

Personally, I believe that opting for a Global Set is generally the Right Thing To Do if the content doesn't really have a place in any existing Single – rather than creating what is essentially "bucket" or container Singles to accommodate it. If your content editors find Globals hard to use/find, consider using the [CP Nav plugin](https://github.com/engram-design/CPNav) to rename the "Globals" tab in the CP to something a little less technical – e.g. "Settings" or "Misc. content". Using CP Nav, you can even add tabs for specific Global Sets, with your own titles – in your case I'd consider creating a set called "Listing settings", adding the fields for the header image and introductory text to that set, and finally creating a tab in CP Nav called "Listings" or the like (or even "Wine Listing" if you want to get really specific), pointing to that particular Global Set. Personally, I think Globals – if done right – is actually better for usability than Singles pretending to be something they're not.


---

