[Support request] PageSpeed penalizing image 31.3 KB not lazily loading?

[Trish]

Hi David,

I kept an exact copy of the CSS code that you supplied, and that I had you remove.
😀 soooo, I simply replaced what I had created with what you provided for the font CSS in the Simply CSS field;

Have now added the Snippet code regarding featured images and REMOVED all of the text from the field titled Skip Images Classes in the a3 Lazy Load settings.

Testing PageSpeed, I see that the mobile speed seems somewhat improved… 73 to 75, as I tested this twice.

The text is STILL a complaint, so I don’t understand???

Initial server response time is now at 1.82s… so, though tech support has never responded to me on regarding my request sent a few days ago, this too seems to have improved.

[David]

Good news is the only font loading now is the Local fonts, and i can see them loading correctly on my browser now 🙂

That snippet i provided for the lazy loading exclusion worked everywhere except for the front page
Can you add this snippet as well.

function skip_lazy_class_first_featured_image_pages($attr) {
  if ( is_singular() ) {
      $attr['class'] .= ' first-featured-image';  
  }
  return $attr;
}
add_filter('wp_get_attachment_image_attributes', 'skip_lazy_class_first_featured_image_pages' );

[Trish]

Hi David,

Have now added the additional PHP script to the SAME snippet as the previous script regarding no lazy loading of featured images. If this code needs to be separated, please let me know.

Mobile loading
Total Blocking Time 60 ms GOOD
Largest Contentful Paint 3.9 s NEEDS IMPROVEMENT
Cumulative Layout Shift 0.153 s NEEDS IMPROVEMENT

So far… even testing the site a second time, there appears to be no improvement. 🙁

[David]

Well the two codes are working. All featured images have the first-featured-image class attached and are reporting that they are NOT lazy loading so that excludes that issue.

Aside from the hugely variable Server response time – still seeing it as high as 8 seconds ( wow ).
See here:

https://www.webpagetest.org/result/211001_AiDcDY_a8bc2e050879a2c704fde5e865c3fda0/1/details/#waterfall_view_step1

Line 45 is where the featured image is loaded, as you can see above it the chain of requests are all short , but the intiial request is taking forever. Definitely soemthing odd with the server

[Trish]

Wow! Is there EVER a looooong server waiting time.

Having not heard back from my website hosting provider’s support regarding the followup I issued on the 27th of September, I initiated a brand new ticket, repeating THAT info and added the URL you provided here, and I stated that there is definitely something amiss with their server… to please advise.

Here’s their response to me:
“The time-to-first-bit metric is a measure of how long it takes for the server to respond to the query with anything including the response header.

The server doesn’t send that until PHP starts generating HTML an html response. PHP doesn’t do that until it can completely load all files it needs to process as well as complete that processing.

The biggest factor to cause long loads, especially if the site is left idle for a while and then requested is disk access times. It has to spend a large amount of time to read all the files from disk back into RAM. once it’s done this it then starts processing which adds a bit more time to the TTFB metric. On follow-up requests, you’ll notice the TTFB is lower because the server doesn’t immediately forget the files it loaded and when it tries to open them again, they’re still in memory and you’re only waiting on the CPU processing time. The server also uses the litespeed API to keep php opcodes cached for a short while so if the site is really busy, the cached PHP opcodes are still there for followup requests and it’s even faster.

It will always fluctuate if your site traffic is not constant. The caches the server uses to try and speed things up are aimed more for busy sites so as the server gets traffic to other sites on the server it will shift the limited disk caching it has (the page cache) to those files, and the PHP opcode cache for your account usually only survives for a few minutes before that memory is released again as well.

At the worst case (with none of your files in page cache, and no php opcode cache, and no caching for that page in wordpress (using the litespeed caching plugin?)[WHICH THEY INSTALLED EARLIER DURING THIS ISSUE] the server has to read every wordpress script file and plugin and theme file off disk which can take a while if the server is busy or you have a lot of plugins (the number of plugins/themes, including inactive ones is a bigger factor here) then it has to process all the code from scratch to generate the page response — this is affected by the complexity of the page being rendered, and the complexity of the plugins your site has loaded and a few other factors) and then transmit it back to you, along with auxiliary content (images, css, js, etc). After it’s done this, the page cache is primed, litespeed caching is primed (if used) and the php opcode cache is primed. These remain primed for a few minutes so followup activity is faster.

If you really wanted to speed the site up and reduce TTFB, you might want to consider switching to one of our WordPress ‘Plus’ packages. They’re pure-ssd drives including all user content and have higher memory and cpu resource allocations. The slowest part of a ‘from-scratch’ request is reading the entire php fileset from disk, and the SSD drives are a hundred times faster at that…”

What a great way to force an UPSELL, huh?!

Anyway… Thank YOU ever so much David, for your focused attention to my site’s issues. This is EXACTLY what I love about GeneratePress… your high quality of support. Two thumbs up!

Many thanks!

[David]

Well that explains it then lol
Sounds like some other site on the shared server is hogging the resources…. but i am not a sever guy so ill leave that to the professionals.

Aside of the fluctuating server times other points to note:

1. The webP conversion of images may have a factor in the slower loading times, if they are having to be processed by your server or a 3rd party server.
2. You may want to look at PerfMatters plugin, to disable scripts that are not required or defer them. Its reasonably cheap for one site. And can make a hell of a difference.

Glad we could be of help!

[Trish]

The host has made it feasible for me to have them charge me the extra, and simply move my website over to their WordPress server.

Will DEFINITELY keep the PerfMatters plugin in mind, as I do have other websites. 😀

Thank YOU again David. You have been super helpful.

Feel free to mark this ticket as resolved.

[David]

Really glad to hear that !!! Thank you for your patience!

[Author]

Posts