loading="lazy" attribute is not applied at all

[lovor]

Steps to reproduce:

Start new WordPress 6.3.1 instance. Use default twenty-twenty-three theme. Create new post. Insert some images. None of the images (including below the fold ones) get loading attribute.

It is expected that below the fold images get loading="lazy" attribute.

[lovor]

After going superficially through the code in media.php, I understood that only the fourth and subsequent images get loading="lazy" attribute, which is not stated in any docs. I will change this to "enhancement" with following suggestions:

• describe in docs exactly how it functions
• change algorithm to take into account image heights and widths to calculate what is above and below the fold - for screen size the most used screen dimension would be taken

[lovor]

Proposal of algorithm for above the fold detection:
Most used screen size is 1920×1080. This may change over time, so put this width and height in variables (perhaps array) and make it filterable.
Assume that images are tiled in a mosaic. In reality, it could be different, according to css, but this is conservative assumption and some images below the fold may omit loading="lazy", and load eagerly, but this is fine.

Calculate, from images widths and heights when image is completely below the fold like this (pseudo-code):

pagewidth = 1920
pageheight = 1080
calcheight = 0
calcwidth = 0
imgcounter = 0
greatestHeightInRow = 0
loop
  calcwidth = calcwidth + img[imgcounter].width
  if (img[imgcounter].height > greatestHeightInRow)
    greatestHeightInRow = img[imgcounter].height
  if (calcwidth > pagewidth) {
    calcwidth = img[imgcounter].width
    calcheight += greatestHeightInRow
    greatestHeightInRow = 0
  }
  // mark image above the fold
  img[imgcounter].aboveTheFold = true
  imgcounter++
until (imgcounter = img.length || greatestHeightInRow > pageheight)
// mark the rest of images below the fold
for (i = imgcounter; i < imgcounter; i++) {
  img[i].aboveTheFold = false
}

[joedolson]

Thanks for reporting! This issue is being tracked in #59550.