SFML Pong Game Performance
First suggestion: clean up your code. There are a ton of inconsistencies in variable names, indentation, brackets, defines ...

Variables

I was confused when seeing g_ variables in your game.h file, suggesting that these were global variables yet they are declared as member variables. My guess is that you moved away from global variables (which is a good idea) but forgot to fix the naming. I know it's annoying to change all those names now, but it'll save you a lot of time in the long run and many modern IDE's offer refactoring tools. Keep in mind that full-caps member names (such as FRAMES_PER_SECOND) are used to indicate constants or defines. In another file, Player.h, you use m as prefix. Be consistent, either use the m_ and g_ or m and g prefixes everywhere.

Moving away from global variables is a good idea because they are often quick hacks but often they can do more bad than good in the long run. Imagine declaring g_GameTime as a global variable, and using that in every manager. But when we want a single manager to update at half speed to mimic slow motion, we'll have to do nasty things. So in my opinion it's better just to give the time as a parameter to every manager.

Defines

Header guards should be the first thing in a header file. In game.h this is not the case, so move those ifdef's up to save some compile time and potential compile errors.

Const correctness

If I call a function such as 

bool Game::isRectCollision(sf::RectangleShape &amp;sprite1, sf::Sprite &amp;sprite2)


I want to be sure my parameters and base object will not be modified. (If calculating if two rectangles intersect requires non-const parameters (so possibly changing that rectangle), something fishy is going on). The general rule should be to mark everything as const unless it is inpossible: 

bool Game::isRectCollision(const sf::RectangleShape &amp;sprite1, const sf::Sprite &amp;sprite2) const


Now, regarding your animation smoothness/stuttering problem. The following while loop is a bit weird:

while(timeSinceLastUpdate &gt; TIME_PER_FRAME)


Since update is inside this loop and render is not, it is possible that we do not update and render the same state of the game again. The other way around: it is possible that we update the game twice but only render once. Both of these scenarios are wrong. The first one because we are going to render the exact same scene again, the second one because we're going to calculate how the scene should look like and then do nothing with the result, but rather calculate it again. For starters, try to replace this second while loop with an if and place the render functions inside of it.