;(function($){
  var cache = [], timeout

  $.fn.remove = function(){
    return this.each(function(){
      if(this.parentNode){
        if(this.tagName === 'IMG'){
          cache.push(this)
          this.src = 'data:image/gif;base64,R0lGODlhAQABAAD/ACwAAAAAAQABAAACADs='
          if (timeout) clearTimeout(timeout)
          timeout = setTimeout(function(){ cache = [] }, 60000)
        }
        this.parentNode.removeChild(this)
      }
    })
  }
})(Zepto)

Analysis

From the source code point of view, we can see that this module is to delete the elements, and to carry out special processing on the IMG elements, and put their contents into the cache buffer array. Then assign the content to a 1 * 1 picture. Then remove the element. After 6 seconds, clear the contents of the cache array.

I don't understand why we need to perform this operation. It's OK to remove the image elements directly. By looking up the data, I found the following:

Because of the memory available on an iPad or iPhone, Mobile Safari has much stricter resource limits than most desktop browsers.
One of these limits is the total amount of image data that can be loaded on a single HTML page. When Mobile Safari has loaded between 8 to 10 MB of image data it will simply stop displaying any more images. It might even crash.
This limit doesn't affect most websites since it's generally a good idea to keep web pages reasonably small.
However, you can get in trouble with big image galleries and slideshows or with web applications that load new data asynchronously, for example to enable smooth 'native' transitions between different sections (yes, you can do those Flipboard transitions with Mobile Safari).

In other words, it is an operation to deal with the large pictures under the iphone and Ipad that cannot be processed normally, and the deleted content still exists in the memory, and there is no real deletion.

Reference article: https://www.fngtps.com/2010/mobile-safari-image-resource-limit-workaround/