After further investigation, it looks like webviewer calculations dont work inside portal rows. So I guess that leaves me with either adding a container field or stacking a bunch of colored boxes on top of each other. Is there any other options I am missing?
Do webviewers take their context into consideration?
They do if you reference context-dependent data – but that point is moot, since you can't have a Web Viewer in each portal row; see here:
You might consider backing up and reconsidering your basic setup. You mentioned two things so far that might hurt your performance: Portals and ExecuteSQL ( ).
Portals can hurt performance over the WAN in some cases because of the record-fetching FileMaker has to do to display them. If you've sorted the portal or the relationship, FileMaker has to fetch all the related records (all fields) over the WAN, and that can slow you down. Another potential bottleneck with portals is portal filtering, which also can hurt you for the same reason (it has to fetch the records to figure out which ones to display).
ExecuteSQL ( ) is a wonderful tool, but not necessarily your best friend performance-wise. This is because FileMaker has to translate the SQL statement into its native binary query language before it can execute. It'll never be as fast, therefore, as native FileMaker functionality.
So if you can recast the solution without these two elements, you might see some performance gains.
Other options include using a Virtual List technique (which will avoid some of the record-fetching problem), using Hide Object When to push unneeded objects out of view (and therefore prevent their being evaluated), or perhaps letting us take a look at your calculations for optimization purposes.