Considering that every
J2EE webapp resides under a URL Context root which is the anchor for each and every resource in the webapp, I don't find it surprising that that particular function is very popular.
On the other hand, I would look more closely to make sure that the function that you THINK is consuming the CPU is really the one that DOES consume the CPU.
I can't fault 70% as a safety margin for webapp operation. Management may press employees to "give 110%", but pull that stunt on machines, and they'll quickly show you what happens when you don't have reserve capacity. I can tolerate 80-85% myself, but that's because I'm in charge of overall keeping things in line and not depending on people who working at 110% to step in when the pressure begins to build.
While it's possible that you can tune some of the higher-level functions to reduce the overall CPU consumption, you might also simply be demanding more than the hardware/software platform can give. I've never been all that certain that I could call JSF a "lightweight" framework, and 300 concurrent users is definitely not casual use.
Fortunately, JSF allows intermingling technologies. If a particular function requires too much, you can swap it out for something more performant, such as
Struts or even raw servlet/JSP without having to scrap the parts of the JSF app that don't have that limitation.