Hi Team,
Both of these are different, but could be closely related.
1.) CSS - I am writing the CSS directly in Views (instead of using Oxygen or Microthemer stylesheet) as seen here: hidden link
I am wondering - is this going to be a performance issue if I write some CSS in Views, some in Microthemer, some in Oxygen... etc. Does Toolset consolidate ALL of the CSS written in Views, into 1 "Views Sylesheet" or something like that?
2.) Database Performance - I have multiple Views on 1 template that pull back a single field displayed on 1 page. So on a given template, I could have 6 or 8 different Views that pull back fields such as: Event name, start date, end date, venue, etc.
I am building it with Oxygen and find it's often easier to create a View for 1 or 2 different fields and substitute them into the template rather than hand-coding the whole thing in Toolset.
But I'm wondering, will this be a performance issue? Should I try to consolidate as much as I can into 1 single View so it queries less on the DB or would this be a non-issue if it can be cached properly?
Hi,
1.) The way CSS code works in the page's processing, it doesn't matter exactly at which place or order it is loaded.
For this reason, there is no drawback in splitting your CSS code into relevant Views and content templates. In fact, it is a good idea to only include the CSS code related to a particular view or content template through that item, as it will ensure sure that those CSS code blocks are not loaded on the pages where they are not needed.
The CSS code that you'll include through Toolset Views and content templates is loaded on the page as inline code, which means that it won't result in extra HTTP requests from external CSS files.
1.) Your observation is correct and each instance of view means a separate query. Ideally, one should try to consolidate the calling of views, as much as possible. However, based on functional and design requirements, you'll often have to use multiple views on a page, so that is fine too.
The cache will significantly help in reducing the complexity of the database queries, however, it doesn't mean that the data won't be called from the database.
I hope this helps.
regards,
Waqar
Hi Waqar,
I am a little concerned as I have this many Views in this particular template...
hidden link
Ha, ha. Do you have any recommendations aside from just combining these Views into lesser number of Views? It's much faster to iterate through the layout this way vs. hand-coding it inside the View. :/
This should be a major concern that a content template has so many views.
( that is why I added a note about this in the other ticket: https://toolset.com/forums/topic/retrieve-custom-field-from-a-cpt-relationship-outside-of-the-repeater-field-grp/#post-1962513 )
At the moment, you're using separate views to show the value for individual custom fields, even when those shortcodes could have been used in the consolidated view because the source or the target posts are the same.
This is not only bad from a performance point of view (since more views mean more database queries), but it also brings in unnecessary complications in terms of usability. An admin will have to remember and keep track of which view is responsible for which "line" and not the complete "section". Even a small change would require cycling through multiple views to update them.
I'm sorry but, I don't see how this current approach is faster or more efficient.
My issue is resolved now. Thank you!
