If we consider projects like a tree of components, then it's best to work your way from the leaves to the core, refactoring the logic to a more central location whether it is the parent component or into a service... This is also a good method to slowly convert from a service centric structure to a more reactive where you might be integrating redux or similar.
Of course, it's best to consider the core or the end of the journey from the leaves before beginning to refactor and try to focus on a single trail so that when staying from another leaf you might find that some of the logic it uses, or could use, you already refactored to a central/parent location.
But often one doesn't get to have that kind of deliberate flow due to timing or having to sneak it into new feature completion... In that case,I would just focus on the singular or internal logic, looking for unused variables, dead code, reusable code and potential memory leaks that do not have an effect on parent or sibling components, or very minimally at least.
When I was refactoring the frontend (Vue.js) I moved a lot of the code into vuex and it definitely helped make the components and views A LOT easier to work with.
But of course deadlines get in the way, I think you're right about about looking for dead code first. Might make it easier to approach the actual refactor.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.