I think these are two (or three perhaps) issues that should not be confused. Time is always time from composition start, not linked to framerate in itself (and framerate/frame-number should never be used to drive animations).

First is the "Fire Periodically" approach. Use a "Divide" node to set the timing - don't enter decimals manually ;). "1" at input A, then your desired framerate as the divisor. In such a workflow, a "Get System Refresh" node or a "Display refresh time" output from a "System Info" node would be beneficial to make "Fire Periodically" nodes more easy to use (Jean Marie). Then it's just a matter of multiplying the output of this node by an integer to get a subdivision that should match up with the system refresh/draw.

Second is excessive event firing in generators/time input compositions. You don't want to link this up to framerate either, but rather limit the incoming triggers to a more suitable rate for the HW you got. To do this; attach an event cable from the "Time" input port to the "Increment" port of a "Count within range" node. Set it to a minimum of 1 and a maximum of 2. Drag the output of this to the "Which" port of a "Select Event out (2)" node, and attach the "Time" input port to the event input of the selector. Now you can use the trigger outputs to drive the composition at half the input rate (you can also play around with increasing the max value to get an in-between rate, but then you will skip frames here and there).

Also when going fullscreen on a retina mac with a shadertoy-shader you are rendering at 4K or whatever the retina displays are. That can be pretty heavy, especially for some of the more experimental stuff done there. Try dividing the Width and Height inputs by 2 if you get these from the input ports/screen info node!

Edit: Framerate is linked to time, but only in the sense that you get the time elapsed from composition start based on which frame you are at