Implementations will typically store the hash value inside the table - this will save lots of hash value calculations.
For the hash value of the key being looked up, it depends on the caller how often that value is calculated. Hash values can be cached. I might have an object with a name, address, and age. And name objects and address objects that cache their hash value, and the hash value of my complete object is calculated from the three hash values of name, address and age. In that case the second call to calculate the hash value of the same object will be quite fast. So the cost of calculating hash codes is very highly variable.
Consider this: Your implementation calculates one hashcode, then determines one or more slots where an item with this hashcode could be stored. Then every time a slot is filled you need to check first if the hash code matches, then if the item matches. The check for matching hash codes is trivial if the hashcode is stored in the table. The cost for comparing items can be high. You will have one successful comparison during a lookup or delete of an existing item, independent of load factor. You may have 0 or more unsuccessful comparisons during any operation, depending on the load factor, but with a good hash function this should happen almost never.
So assuming that calculating hash codes and comparing items are expensive, the other cost is likely quite trivial. (Why would they be expensive? For example strings are most likely Unicode strings, and Unicode strings with different representations can be equal, so comparison and calculating the hash code are not trivial. )