This is a tricky one to solve and get meaningful data.
Firstly, what defines a "word"? Usually in a text editing program this would be defined as a series of alphanumeric characters separated by a space or a new line character. That gets pretty tricky in an OS that uses those 2 keys for other options like QuickView, and enter in save dialogues and the like.
Many apps simply do not input text in a way that would make a words per minute count useful, for example safari. Would typing URLs of filling in forms provide any meaningful data, or would it just trash the more useful bits of your statistics etc.
You may be better served looking for a writing app that does this (such as this one for example - others exist) and is able to understand when it is actively being used, and when it is minimised etc, so that you are only capturing the info when you are actually doing something worth of monitoring.
To help in this there is a great tool called QuickCursor that will allow you to switch any text input field to the text editor of your choice. That way once you have found a program that you like for typing in that offers a WPM count feature, you can then use that program for all your typing by switching to it with a keyboard shortcut from any place where you need to type, including email/web forms etc, and then switching back and taking the contents with you.
Having said all the above, there is an app called TypingStats that will just sit on your menu bar and take systemwide statistics, on the proviso that it only actually guesses at your WPM by counting every 5th keystroke as a "word" and then doing the maths to give you an approximation.
The only surefire way to avoid having JavaScript trap keyboard input is to disable JavaScript in the browser.
I understand you'd like to leave JavaScript on, but it is designed to pass near total control of raw key presses to the browser and not to the app once the OS hands it input data. This means you would need a specific code solution for each implementation of keyboard filtering on potentially each individual page/site to ensure arbitrary key chords like Command H get sent to Safari instead of JavaScript.
See these links for an overview of how key presses are handled:
The last link is a tester to show you the raw events and you will see that even a brief ⌘Q can be trapped by JavaScript if the website developer wishes to do so.
Best Answer
Try "TypeFU", from the Mac AppStore...