Optimizing minHeap implementation
Without more information what, when asked for a reason for two "time limit exceeded" results, motivated your teacher to mention the possibility to "get" a faster minHeap, you deprive yourself of getting more useful answers. See How to get the best value out of Code Review - Asking Questions
First and foremost, just what is the task timed?
I can't see anything seriously detrimental in your implementation:
I guess a bigger task than, say, handle a batch of insertions and min extractions gets timed, in need of an algorithmic improvement more likely than any tuning.



That said, there are principles like YAGNI, KISS and DRY.
Let me start with the bright side of YAGNI - You Are Gonna Need It:


Documentation. The type that does not get separated from the code:
Documentation in the code


Otherwise, the code presented looks a pretty decent beginner's stab at coding a heap.
Catch:  


There are omissions from the deletes:
• not relevant when using an array of primitives as presented in the question:
 Failing to set the reference at the index deallocated to something innocent (as null) does not immediately impede garbage collection, as it gets copied to a lower index. Enter the next delete…


bug in delete(int d):
It replaces element atD with formerLast and restores the heap relations in formerLast and its descendants.
But what about its ancestors?
Not to worry if
1) it ends up at an index abode d or
a) it was a descendant of atD: none of those has higher priority
There are many ways to handle the situation -
I'd prefer just dropping delete(int d) over just calling bubbleUp() or some elaborate handling trying to keep the number of comparisons low.



Room for improvement:


Part of Don't Repeat Yourself is using interfaces:
Define an interface for an, um, PriorityCollection&lt;E&gt; extends Collection&lt;E&gt;.
One advantage is that implementations don't get to reduce visibility of interface methods like isEmpty().
Another is inheriting documentation, too.
• have an E extractTop() return the top priority element it just removed from the Collection
• nowadays, Java interfaces can include unit test code, too.  
Keep It Short&amp;Simple meets You Ain't Gonna Need It in fixing arity at 2:
• simpler/shorter code
• fixes a naming issue in d (maximal degree?)
• maximises information in relative position of keys
• doesn't show in the interface, anyway  




If and when competent (&rarr; framework) measurements suggest the performance being a problem,
• consider returning to an array of primitives.
• If the cost of comparing elements is high, change tactics in bubbleDown(sink?): find the path along which to sink/bubble down, and look for elements that should stay in place starting from the bottom: this may almost half the number of comparisons.
• an E replaceTop(E replacement) may save considerable work
  it may be useful to additionally have the similar E addAndExtractTop(E addition)