considerations when using triggers on a replicated (target) database
This sounds like a great situation to use indexed views. These are pretty much what they sound like: a view that physically stores its results in the database, and is updated automatically when the base tables are updated.

A few cautions:


Having a lot of these in your subscription database could slow down replication (but so could lots of triggers).
There are some strict SET options you need to change in order to create them, and you have to use WITH SCHEMABINDING when creating the view.
There are additional strict requirements about what can be in your view. For example, you can't use outer joins, aggregates, or cross/outer apply.
If you're using Standard Edition, you need to query the view by name using the WITH (NOEXPAND) hint. SQL Server won't automatically use the view if you attempt to query its base tables.


There's (a lot) more detail in this article, as well as a nice example using the AdventureWorks database:
http://msdn.microsoft.com/en-us/library/ms191432%28v=sql.100%29.aspx

If it's a relatively simple query that's only performing poorly because of a lot of data and (inner) joins, this could be an easy way to improve it.