I think the answer to your question is simple: stop shrinking tempdb. If your workload requires a tempdb size of, say, 200 GB, let it stay at that size. It's pointless to shrink something that will grow again.
Even more so, when it comes to the log file, size growing a log file always takes resources when SQL Server has to zero out the newly allocated area. The same is true for the data file, if the service account for SQL Server does not have the permission Perform Volume Maintenance Task. (Which it should have under normal circumstances.) And if you some inexplicable reason have to clear the plan cache, you are adding more insult to injury.
So that is the answer to your question: stop shrinking tempdb.
As for why you think that you need to clear the plan cache, my guess is that to shrink the log file, the active portion have to be at the beginning of the file. DBCC FREEPROCCACHE is not going to change that, but as tempdb is being used, time will move it, so you could just as well try DBCC HAVE_SOME_PATIENCE next time. Except, there will not be a next time, because you have now learnt that you not shrink tempdb on regular basis.