When designing for performance, you need to consider not only the insert/update requirement but also the query requirements
What people often forget is that 99% of the time you'll be querying data, and less than 1% of the time you'll be querying the data.
The approach outlined by Ilja is a good normalized design which eliminates repeated groups and will work with any number of parameters.
However very often you'd want to run a query which says give me all widgets with colour = red, and visibility = true and nested = false
Now if you have a fully normalized schema, you'll have to use correlated subqueries (with EXISTS clause) or IN clauses and either way query optimization can be a challenge. If you have a limited number of attributes you can put them as columns in the same table so you'll end up with
If you don't know what additional attributes you might have, create holder attributes ATTRIBUTE1, ATTRIBUTE2... (common practice in packaged apps where user defined attributes are needed), and create/update view which can map the attributes.
Now you can run a simple query
With the right indexes on your common attribute choices, you can have fast queries.