In homepage 2 resources are being parsed using HTTP/1.1 instead of HTTP/2

Hi Diego,

Good day to you. Thanks for using our plugin SuperPWA and for the kind words. As you haven’t mentioned the web address over the forum, could you please let me know whether the images which are loading as HTTP/1.1 are same as you added via our Settings page for Application Icon & Splash screen or not?

Looking forward.

Hi Jose,

The images are not the same as the ones I added via your Settings page for the Application Icon and the Splash screen.

A few hours ago I sent you a message enclosing the web address, using your contact form present in the Super PWA website (https://superpwa.com/contact/).

Please, let me know if you need anything else.

Thank you!

• This reply was modified 5 years, 11 months ago by diegocanal.

Hi Jose,

Good day to you. I granted you access to my site. You found out that the root of the problem was Super PWA and another of my plugins (Lazy Loader) colliding, but we never got to any conclusions about the reason why they were actually colliding –and only on the homepage and not on any other pages of the same site–.

Any news on this?

Looking forward.

I think we fixed this over the mail after some good number of tests and also noticed that a LazyLoad plugin caused the issue? Isn’t it?

Earlier during my test, I noticed that upon the inner pages (other than the homepage) the images are not loading as HTTP/1.1 and all files (images) are loading as HTTP/2 even though the LazyLoad plugin is activated. I think most probably it will be caused either because of the small images on homepage (as I tried testing the same after removing those small icons, and cannot notice the HTTP/1.1 error upon those cases) or otherwise, the Lazyload plugin which you used is delaying for more time than the usual for the loading of those small images.

I didn’t get enough time to test more into it as I’m running over a limited time.

Hello Jose,

I think we fixed this over the mail after some good number of tests and also noticed that a LazyLoad plugin caused the issue? Isn’t it?

I think it isn’t. There must have been a misunderstanding somewhere because:

• On the one hand, the LazyLoad plugin does not cause the issue if I keep Super PWA inactive. I have other 51 active plugins on the site and only when Super PWA is active the issue occurs. On the other hand, if Super PWA is active and I keep the LazyLoad plugin inactive then the issue goes away. That means that in order to experience the issue both plugins must be active at the same time, which makes me think that they are colliding somehow as on their own they don’t cause the issue.
• From my point of view the issue has not really been fixed. I simply implemented a temporary patch. I added a ‘do-not-lazy-load’ class to those two images that were experiencing the issue, but they should be lazyloaded in normal conditions.

Earlier during my test, I noticed that upon the inner pages (other than the homepage) the images are not loading as HTTP/1.1 and all files (images) are loading as HTTP/2 even though the LazyLoad plugin is activated.

That exactly matches my initial description of the issue in this support topic.

I think most probably it will be caused either because of the small images on homepage (as I tried testing the same after removing those small icons, and cannot notice the HTTP/1.1 error upon those cases) or otherwise, the Lazyload plugin which you used is delaying for more time than the usual for the loading of those small images.

I think that among your 2 hypothesis the second one is the right one, that the issue has to do with the loading timings.

I’ve been investigating a bit and I’ve noticed that in the responsive mode in Chrome Dev Tools, if I choose a small device like an iPhone 6/7/8 in portrait mode, the waterfall (in the Network tab) shows me that the two problematic images are the only ones loaded after the page has been fully loaded (to the right of the vertical red line of the waterfall) –that is because the device is small enough as to not need those images (they are not shown above the fold)–, please take a look at the screenshot before activating Super PWA and the screenshot after having activated Super PWA.

At first sight it seems that with any lazyload plugin there will be some rare circumstances in which some images are going to experience this issue –when they are just beneath the fold, so the lazy load plugin is going to load them just after the page has fully loaded–.

Do you think there is a solution to solve this issue? Perhaps it would be possible to modify the service worker to load the resources using http/2 instead of http/1.1, is that viable? Any thoughts?

Looking forward to your comments.

As from the screenshot you shared over last comment, the two images (the images which are loading over the HTTP/1.1 protocol while SuperPWA is active) are loading after the complete loading of the page (I mentioned about the condition when SuperPWA is inactive). Isn’t it? Why it’s loading very slowly? I’m little bit curious to know the reason.

If by ‘slow’ you mean why those two images are loading after the page is fully loaded then I would say it’s because the lazy loader first loads the images that are absolutely necessary –the ones that are within the first visible area before we do any scrolling at all (above the fold)– and afterwards, once the page is fully loaded, it loads the two images that are just below the fold, i.e., the first ones we’re going to need as soon as we start scrolling. The lazyloader script is being smart enough to know what the next images are going to be needed, but because it wants to prioritize the full load of the page, it loads them right after it’s done (the full load).

You can take a look at the lazy loader documentation at GitHub, it is called “lazysizes” –a very popular and high performant lazy loader in and out of the WordPress community–. Here you have a description of its specific option, called “expand”, that, as its developer describes, “will expand the viewport area to lazy preload images/iframes which might become visible soon”. Notice how he uses the term preload (as opposed to load).

I hope you have noticed that I included 2 screenshots, one with Super PWA inactive and the other one with Super PWA active. In both screenshots the two images are loaded after the page has been fully loaded.

I’ll explain my question a bit more – Even though there exists a lot of images can be noticed (below the fold) even after scrolling down from those 2 images, are not seen to be delaying and are loading over lazyload upon the website. Why only 2 small sized images of size 700 Bytes are loading after the full page load?

Even though there exists a lot of images can be noticed (below the fold) even after scrolling down from those 2 images, are not seen to be delaying and are loading over lazyload upon the website

I think you’re referring to images that are not loaded by the lazy loader, like minus-24px.png, and that is because they come from a stylesheet (e.g. background: url(https://www.debelareabogados.es/wp-content/themes/modernize-child/images/icon/dark/minus-24px.png) no-repeat;). There is one, debelare-abogados-madrid-contacto-03-op.jpg, that is not being lazy loaded but it is for another reason that is too long to explain.

In short, I cannot see images located below the 2 that are affected by the issue, and that are not loaded via stylesheets, which are loaded before we start scrolling. If you see them –apart from debelare-abogados-madrid-contacto-03-op.jpg, which is a special case– could you please give me an example?

• This reply was modified 5 years, 11 months ago by diegocanal.
• This reply was modified 5 years, 11 months ago by diegocanal.
• This reply was modified 5 years, 11 months ago by diegocanal.
• This reply was modified 5 years, 11 months ago by diegocanal.
• This reply was modified 5 years, 11 months ago by diegocanal.

Since yesterday I’ve done some improvements to clean up the initial loading of images so we can work with less noise. I’ve implemented lazysizes’ unveilhooks extension so now all the background images (required by stylesheets) are lazy loaded too. I also fixed the debelare-abogados-madrid-contacto-03-op.jpg image that was being wrongly loaded before it was really needed –as it was in the footer–.

But no matter the aforementioned improvements, the situation is the same. I enclose the following screenshot with some notes. You can take a look yourself at the staging site I shared with you.

Also I wanted to point out that if you were referring to “slowness” from an absolute point of view, notice that the page fully loads in 720 ms (milliseconds) and that the last image that is downloaded (one of the two that experience the issue) is so at 1.7 seconds of the timeline.

• This reply was modified 5 years, 11 months ago by diegocanal.

Hi there,

Good day to you. I discussed this issue with a top PWA developer over the field and he told told me that loading of images/any resources after the registration of service worker will be considered as HTTP/1.1. IE; service worker registration will wait till the resources get loaded, upon your case two images are loading after the service worker registration.

Due to that, it’s better to make some tweaks over your code for those two images to load before the service worker get registered.

As two images over your website is taking some time to load after loading of other images and registration of service worker, some manual tweaks at your end to exclude those images from lazy load will only be the solution right now to resolve it.

Hope that helps you.

Hi Jose,

I’m glad there’s been some progress on this matter.

So now we know for sure that after the registration of the service worker all the resources will be loaded using HTTP/1.1 and that it’s no possible to change that behaviour (use HTTP2 instead) –I wonder… Wouldn’t it be faster if the browser loaded them using HTTP2? Is it a limitation imposed by the current browsers design?– anyway it seem there is nothing we can do about it.

I will keep an eye on it and see if this happens in different scenarios (pages and websites). If it did it would be a pain to have to manually tune up images when using lazy loading.

Perhaps I should open an issue on GitHub’s Lighthouse repo as I have the impression that, even if I don’t prevent this issue from happening, it wont negatively impact on the user experience (First Meaningful Paint, Time to Interactive, etc). What’s your opinion?

Thank you!

anyway it seem there is nothing we can do about it.

As upon your website, only two images (those small ones) are getting loaded after the registration of Service Worker (which is only on the HomePage) and rest of the pages are not getting this problem as those images are not within those. Try to exclude those images from the lazy load or set the priority of loading of images to high, I think it will help you. And moreover, that’s the only solution I can recommend you at this time.

In the production site I have those 2 images excluded from being lazy loaded and it’s working fine.

I’ll keep an eye on this type of issue in the rest of the websites in which I’m going to install Super PWA. I’ll try to set up a system to automatically run Lighthouse in all the pages of all of my sites and get consolidated reports. If I encountered this issue again I would get back to this thread to report it.

Thanks Jose for your efforts, patience and diligence providing me with great support :).

Good to hear that from you and hope you’ll try our plugin on some other websites too and do let us know whether you notice somewhat similar issues over any other websites.

Have a great day