Hi dear;
I am trying to speed up my website in compliance with google page dev.
Starting with the demo site I find that LCP is of 3 seconds. Which should be below 2.5 seconds in order to get valid indexing by google.
Can you pls help understand where to start fixing this. Mainly we need focus on the Eliminate Render blocks and Critical Chain Requests as per what I dug up using Google.
Help shall be deeply appreciated ;
Thank you in advance;
Very warm Regds./
radhavallabh
Page Speed Issue
-
radhavallabh
- Senior Contributor
- Posts: 466
- Joined: Tue Oct 27, 2020 4:09 am
- Phoenix Version: 1.1.0.6
- Has thanked: 29 times
- Been thanked: 3 times
-
ecartz
- Core Team
- Posts: 3084
- Joined: Tue Nov 05, 2019 6:02 pm
- Phoenix Version:
- Has thanked: 4 times
- Been thanked: 208 times
Re: Page Speed Issue
1. Reduce server response time.
This is just a better host (or at least a better server from the host). We chose demo hosting to be inexpensive rather than performant. My personal demo site doesn't show this.
2. Eliminate render blocking resources.
We use the standard Bootstrap CSS. Advantage: almost everyone already has it cached. Disadvantage: if someone does not have it cached, it's a larger file. Also see #5.
3. Server images in next-gen formats.
They mean that they want you to use WebP or AVIF.
4. Properly size images.
This is your setup. My demo site also gets this, because it uses the original images rather than carefully sized images. But this is entirely addressable by customizing your images.
5. Reduce unused CSS.
Also relates to #2. What they are saying is that they want you to use (instead of the standard Bootstrap CSS), a special version that removes any unused class definitions. And then of course they'd want you to minify it. I think I speak for the entire Phoenix Cart team when I say that we'd be willing to work on getting such replacement CSS files onto CloudFlare if one was made. But for right now, we don't have the resources to create the file. I don't work with building Bootstrap CSS, so it would be new work for me. One of the certified developers might have more experience with such things.
Note that Google would actually prefer that you buy your own CloudFlare placement and merge the user.css file into the (now reduced) Bootstrap file. Making such a file would definitely be certified developer work, not core work.
They'd also like to split the CSS into two groups (more for #2 than #5). One would determine things like size and placement. The other would do things like colors. The size and placement one would go in the head. The colors one would go in the bottom of the body.
A really advanced solution would check if Bootstrap was cached and only load the custom file if it was not. Otherwise, it would load user.css instead. Not sure what would be involved with making that work. Again, user.css should be stored on a CDN (CloudFlare is an example but not the only possibility; probably best to put all files on the same CDN though so as to minimize DNS requests--another thing about which Google will warn).
For #3 and #4, Rainer has Kiss IT Pro to help. It can make images that exactly fit their viewports in a variety of formats, including WebP. That would help with both issues. I mean, one is literally asking to switch to WebP (or AVIF). The other says that the image files are too big. Making the image the exact size of the viewport would help with that. And presumably you could also potentially turn down the image quality. But I'd try a smaller image in an otherwise lossless format first. You might find that was plenty. If not, you could escalate to a lossy format, possibly with lower quality.
You could also do that manually with each image. Kiss IT Pro makes it easier. It's already possible.
Note that I didn't mention Critical Chain Requests. This is because they are not showing that as a problem. You might conceivably reduce it slightly by preloading the fonts. But Google doesn't find the current two layers to be excessive chaining. As shown at Notice how the circle is empty, not red or orange. That's because they are happy with our relatively small depth of chained requests. Only two level two requests. No level threes or more. This is not a serious issue with Phoenix, so it's not something we could fix. As I said, it might be possible to make the two font requests level one, so we have no level twos. That would be a slight improvement.
This is just a better host (or at least a better server from the host). We chose demo hosting to be inexpensive rather than performant. My personal demo site doesn't show this.
2. Eliminate render blocking resources.
We use the standard Bootstrap CSS. Advantage: almost everyone already has it cached. Disadvantage: if someone does not have it cached, it's a larger file. Also see #5.
3. Server images in next-gen formats.
They mean that they want you to use WebP or AVIF.
4. Properly size images.
This is your setup. My demo site also gets this, because it uses the original images rather than carefully sized images. But this is entirely addressable by customizing your images.
5. Reduce unused CSS.
Also relates to #2. What they are saying is that they want you to use (instead of the standard Bootstrap CSS), a special version that removes any unused class definitions. And then of course they'd want you to minify it. I think I speak for the entire Phoenix Cart team when I say that we'd be willing to work on getting such replacement CSS files onto CloudFlare if one was made. But for right now, we don't have the resources to create the file. I don't work with building Bootstrap CSS, so it would be new work for me. One of the certified developers might have more experience with such things.
Note that Google would actually prefer that you buy your own CloudFlare placement and merge the user.css file into the (now reduced) Bootstrap file. Making such a file would definitely be certified developer work, not core work.
They'd also like to split the CSS into two groups (more for #2 than #5). One would determine things like size and placement. The other would do things like colors. The size and placement one would go in the head. The colors one would go in the bottom of the body.
A really advanced solution would check if Bootstrap was cached and only load the custom file if it was not. Otherwise, it would load user.css instead. Not sure what would be involved with making that work. Again, user.css should be stored on a CDN (CloudFlare is an example but not the only possibility; probably best to put all files on the same CDN though so as to minimize DNS requests--another thing about which Google will warn).
For #3 and #4, Rainer has Kiss IT Pro to help. It can make images that exactly fit their viewports in a variety of formats, including WebP. That would help with both issues. I mean, one is literally asking to switch to WebP (or AVIF). The other says that the image files are too big. Making the image the exact size of the viewport would help with that. And presumably you could also potentially turn down the image quality. But I'd try a smaller image in an otherwise lossless format first. You might find that was plenty. If not, you could escalate to a lossy format, possibly with lower quality.
You could also do that manually with each image. Kiss IT Pro makes it easier. It's already possible.
Note that I didn't mention Critical Chain Requests. This is because they are not showing that as a problem. You might conceivably reduce it slightly by preloading the fonts. But Google doesn't find the current two layers to be excessive chaining. As shown at Notice how the circle is empty, not red or orange. That's because they are happy with our relatively small depth of chained requests. Only two level two requests. No level threes or more. This is not a serious issue with Phoenix, so it's not something we could fix. As I said, it might be possible to make the two font requests level one, so we have no level twos. That would be a slight improvement.
You do not have the required permissions to view the files attached to this post.