AMPXF - AMP for Xenforo 2

AMPXF - AMP for Xenforo 2 [Paid] 1.4.9

No permission to buy (€50.00)
Maybe it's the language barrier, but as I understand it.
You shouldn't "talk" in mocking phrases, but - like me - provide facts that are easy to understand ...
Again, those are scores, not speed measurement. )
How do I know, maybe you don't have redis enabled and don't cache pages for guests and css with Cloudflare, and that's why you got such improvement in the score using ampxf. But did you get improvement in core web vitals?
 
You shouldn't "talk" in mocking phrases, but - like me - provide facts that are easy to understand ...
I posted these pictures on the 20th of Jan, the day I installed the add-on.
My regular page speed
xf-jpg.244469


It's amp version

amp-jpg.244470


FCP & LCP almost twice bigger. The answer was "I'll take a look later tonight".
A month has gone, now my answers are ignored, and I better zip it up. )
 
Again, those are scores, not speed measurement. )
These "scores" are made up of points of different importance, including "speed measurement", and therefore say more than your individual considerations.
Everything necessary can therefore be seen from the previously posted graphics.
Especially the difference with and without AMP

How do I know, maybe you don't have redis enabled and don't cache pages for guests and css with Cloudflare, and that's why you got such improvement in the score using ampxf. But did you get improvement in core web vitals?
Even further back in the topic I also posted graphics on Core Web Vitals, these clearly show how our mobile pages change from "poor" (red) to "good" (green) at speed since AMP has been running.

When it comes to protecting user data, AMP pages are already a risk because the pages are loaded from the Google cache and google receives the ip addresses of our users.
But that is nothing compared to what Cloudflare sees. Therefore, in the interest of our users, I would never use things like Cloudflare.

Of course we use REDIS, it saves a lot of database access and thus keeps the load low. But we also used Redis without AMP so that the use of Redis does not play a role here.
 
I posted these pictures on the 20th of Jan, the day I installed the add-on.
My regular page speed
xf-jpg.244469

Sorry but this data is incomprehensible.
I don't see which site or with which tool was scanned and I can't check it that way.
In contrast, in my graphics you can always see which url were scanned with Pagespeed Insights and everyone can check that.
Anyone can call up the page and see if and how many ads appear there. If I turn off the ads, my mobile pages are fast even without AMP, but that's what this topic is all about.
It's about the fact that mobile pages are as fast as possible, even with advertising. They are not without AMP, with AMP they are ...
 
I posted these pictures on the 20th of Jan, the day I installed the add-on.
My regular page speed
xf-jpg.244469


It's amp version

amp-jpg.244470


FCP & LCP almost twice bigger. The answer was "I'll take a look later tonight".
A month has gone, now my answers are ignored, and I better zip it up. )

This is not a valid comparison.

It makes sense on paper, but it's not because AMP does not SERVE from your domain. It merely collects it as a source document.
Google cache's it. It serve's from The AMP Cache.

If you want to run a lighthouse on it, your url needs to have ampproject.org in it.
 
Last edited:
This is not a valid comparison.

It makes sense on paper, but it's not because AMP does not SERVE from your domain. It merely collects it as a source document.
Google cache's it. It serve's from The AMP Cache.

If you want to run a lighthouse on it, your url needs to have ampproject.org in it.
doesn't make much of a difference

1 (2).webp

2.webp
 
The tool performs a redirect to source too it seems, which is not what actually happens to a user. A user loads directly from cache, not from source.

I'm not sure what the correct way to test it is, but this isn't it.
 
The tool performs a redirect to source too it seems
then it probably would show the same numbers as on the first picture.
do you mean your amp pages have better core web vitals than your regular pages, or you just don't care and didn't compare?
 
Why should we only stare blindly at those 2 stats which are part of the full score, when Google's own tool says it is good?
I stated at the very beginning that I don't know anything about it. I just follow the link PageSpeed Insight shows me.


Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools... The current set for 2020 focuses on three aspects of the user experience—loading, interactivity, and visual stability—and includes the following metrics (and their respective thresholds): LCP (2.5 seconds), FID (100 milliseconds), CLS (0.1)... Tools that assess Core Web Vitals compliance should consider a page passing if it meets the recommended targets at the 75th percentile for all of the above three metrics.

As LCP of my amp pages is about 500ms short to get into "2.5s" and PSInsight says that all.css is blocking rendering, I'm asking if it's possible to do something about it.
 
I stated at the very beginning that I don't know anything about it. I just follow the link PageSpeed Insight shows me.




As LCP of my amp pages is about 500ms short to get into "2.5s" and PSInsight says that all.css is blocking rendering, I'm asking if it's possible to do something about it.
I'll take a closer look at if we could load the fontawesome icons from local server instead of the CDN and that way shave off some milliseconds from the load time. 👍

As for "double load":
FA seems to load both solid and regular fonts when the "regular" is used.. This is also the case for default XF as you can see in the template font_awesome_setup.

So I guess if you use the solid font on the site it only needs to load one single font. While the CDN loaded will be regular, with solid loaded as well.
 
I'll take a closer look at if we could load the fontawesome icons from local server instead of the CDN and that way shave off some milliseconds from the load time. 👍
Thank you!
As for "double load":
FA seems to load both solid and regular fonts when the "regular" is used.. This is also the case for default XF as you can see in the template font_awesome_setup.
Right. By default, xF has selected regular and loads both regular & solid. When it's changed to "Solid" in style properties, it loads solid only.

So I guess if you use the solid font on the site it only needs to load one single font. While the CDN loaded will be regular, with solid loaded as well.
Hallelujah! )
 
Just to prevent misunderstandings. I pay either € 50 or € 250 once. And for the annual renewal 15 € or 60 € once a year? Is it correct that way?
 
One question, how does the renewal work? When the year is over, does the addon stop working like the AMP Robots not visiting anymore?

Or it is like other addons where the addon keeps working but one doesn't have access to the newer versions?
 
One question, how does the renewal work? When the year is over, does the addon stop working like the AMP Robots not visiting anymore?

Or it is like other addons where the addon keeps working but one doesn't have access to the newer versions?
The amp robot will stop visiting if no active license exists, and the addon can still be used at the current version. If you want access to newer versions then you will need to renew the license.
 
I'll take a closer look at if we could load the fontawesome icons from local server instead of the CDN and that way shave off some milliseconds from the load time. 👍
This is possible I think as I load my custom google font locally also.

1614349956834.webp
 
Top Bottom