It sounds like a broad topic. You may want to screencast short sessions of yourself coding, and then run them back to see what's taking longer. Here are some more thoughts:

1) Research: Do you find that you don't understand documentation of libraries, or don't understand what makes one library better than another when you're looking through your options (popular / common libraries)? I don't think this is necessarily indicative of slow cognitive skills. I think it's indicative of perhaps not asking the right questions when you go through the libraries to pick one in the first place. As soon as you start trying to decide for yourself whether you prefer one library over another or start seeing strengths / weaknesses in the libraries you do / do not choose, this is a sign you are probably starting to "get it".

2) Implementing the library: Do you read the documentation first? Or do you go straight to examples? Bypassing documentation is not always a good thing. Take the time up front to get familiar with what you're working with so you have a good overview and understand in general how one would perform tasks with the library and how the author intended it to be used. If documentation is sparse, look at the code. Is it a highly popular library and you're still having trouble understanding? If so it's not necessarily indicative of slow cognitive skills. Just spend more time reading others' code. By flexing that muscle (like with other mental exercises) it should improve with time.

3) Specifications. Does the company / client provide specifications? Or are you on your own and need to research the requirements of the project from scratch in order to assess what the project needs. Depending on the specifics and what the company / client's expectations are you may want to consider if cutting corners is appropriate. For example is this a Minimum Viable Product? If so cutting corners is probably ok as long as it meets requirements of the project. That's not necessarily a tip for improving but a practical point in that it's never useful to write code for a project that will never be used, so having a clear idea of requirements for the project is critical in order to know what can or cannot be left out of the implementation.

4) How often do you think abstractly about the problems you're trying to solve? Generally speaking in order to truly harness the power of programming and improve your speed to get common tasks done quickly, you should find ways to write layers of code just beneath your specific implementation to facilitate the implementation of common components (for example, an authentication system).

It's also sometimes a good idea to practice writing the entire component (if not for work then in spare time) from scratch. This way you will have gone through all the agony yourself and understand the real pain points in implementing components for a system and will be better equipped to choose libraries that truly help you to accomplish what you're trying to accomplish. If you've done this a number of times and still wouldn't be able to identify pain points or have ideas for how to abstract common tasks into libraries / classes of their own, then you may just not be thinking critically enough about the problems you're trying to solve.