Have you found root cause of why the tempdb is so large in the first place? If you don't fix the problem, it's just going to grow back that size. Shrinking it will only cause significant performance issues as it extends.

Tempdb is used for a couple of things... sorts that don't fit in memory, and temporary objects (ie. temp tables)

A couple things to look at, if you haven't already:

1) SQL Tuning...

a. Look for nested-loop joins and SORT operators in you plans.

b. Look for the use of temporary objects. This is a common and acceptable practice. If your application(s) make lots of use of them, your growth might just be "nature of the beast".

2) Index tuning...

a. Organizing/re-ordering/creation of indexes causes sorts, and often on disk. Look for indexes that aren't being used. A pleasant side-effect will also be improved DML performance 🙂

b. Also consider a periodic maintenance plan that re-organizes indexes and updates statistics.

Also, remember, tempdb is instance level, not database level... so SQL and Indexes in ALL your databases in that instance need to be evaluated.

Once you've ruled out the causes, then consider shrinking tempdb. You can monitor page usage within the file to see what the new high-water marks are, and if there is any improvement. The "delete and restart" trick will provide you with an empty tempdb to start your testing and analysis with. Once you know the usage after any tuning, then I recommend shrinking to that size plus 10%, if you shrink at all.

Just blindly shrinking is never a good approach. It's that big for a reason, and will always grow to that size again no matter how many times you shrink it.

Good luck! Let me know if you need any help with the tuning.