Dedicated table to back up UI component to avoid expensive query with multiple joins

I faced situation when query which fetches data for UI component is running too slow using many JOINs. Indexes were created where possible, but it's still too slow and hard to optimize as execution plan changes as user changes sort column and thus ORDER BY.

I wonder is it a good idea to create dedicated table which will back up this UI component, and create AFTER INSERT/UPDATE triggers on tables which were joined by the query, considering that triggers won't significantly affect insertion and updation.

To narrow the question: does this practice exist and should it be considered good or bad in such situation? Is cost of creating unnecessary dependencies in the system with TRIGGERs too high?