Which schema is better for a shopping project?
You are much better off using the EAV (entity-attribute-value) approach for a product feature catalog.  The approach is transportable to any SQL platform as it doesn't rely on a particular feature of Postgresql (JSON columns).

All of the usual arguments against EAV don't apply to a product feature catalog, since product feature values are generally only regurgitated into a list or worst case into a comparison table.  

Using a JSON column type takes your ability to enforce any data constraints out of the database and forces it into your application logic.  Also, using one attributes table for every category has the following disadvantages:


It doesn't scale well if you eventually have hundreds of categories (or more).  
If you change the allowable attributes on a category you have to change a table definition instead of just adding or removing rows in category_fields
You may still end up with sparsely populated tables if the product has many potential features only a small subset of which are known.


It is not especially difficult to retrieve data about a product with specific features.  It is arguably easier to create a dynamic SQL using the EAV model than it would be using the table-per-category model.  In table-per-category, you need reflection (or your JSON) to find out what the feature column names are.  Then you can build a list of items for a where clause.  In the EAV model, the WHERE X AND Y AND Z becomes INNER JOIN X INNER JOIN Y INNER JOIN Z, so the query is a little more complicated, but the logic to build the query is still totally table-driven and it will be more than scalable enough if you have the proper indexes built.

There are a lot of reasons not to use EAV as a general approach.  Those reasons don't apply to a product feature catalog so there is nothing wrong with EAV in this specific application.