Eliminate render blocking resources

When I run a web page through Google Page Speed Insites whilst the Desktop returns a score of 99% the Mobile score is always downgraded due to the files that Xara creates on publishing, namely:

• ani.css
• roe.js
• prs4.js (?)
• jquery.js

These render blocking resources have something that Xara users have no control over, they are created on Publish.

Would it be possible for the Xara devs to reconfigure these resources to load more efficiently?

Attached shows loading the page on a Mobile. It gives a 1.67 seconds delay on page rendering. This is consistant for any mobile page xara creates.

For example as a test THIS is a page that has one single tiny image and one text content set to Heading1 and one set to Normal Text.

The Google Page Speed Insites test still create a large Render Blocking result and marks it 81% which is pathetic.

Quote:

---

Originally Posted by Egg Bramhill

When I run a web page through Google Page Speed Insites whilst the Desktop returns a score of 99% the Mobile score is always downgraded due to the files that Xara creates on publishing, namely:

• ani.css
• roe.js
• prs4.js (?)
• jquery.js

These render blocking resources have something that Xara users have no control over, they are created on Publish.

---

Any idea why these files don't negatively impact the Desktop scores?

Egg, this is difficult.

Your example page hits 81% in Insights but using Lighthouse directly, I get 100%.

Your page is not a true mobile one; way too wide so I suspect it is being rendered twice. The second to fit to a mobile view.
I have a separate 6-page transitions phone site that hits 99%.
I have a separate 6-page scrolling mobile site that hits 98%.

The assets are required as follows:

• ani.css - small CSS Library (100kB) used for page Transitions and web animations. Can be avoided in Conventional and Scrolling sites saving ~400mS.
• jquery.js - similar to above.

After first access, these are cached so the hit is lessened very quickly.
Xara needs to update ani.css as it has with jQuery recently. This will improve performance a tad.
You could use a CDN link to jQuery. This assumes the user has visited other sites and has a cached jQuery already.

roe.js & prs4.js are Xara essentials so need to be upfront otherwise the site jumps around until everything is loaded up.

Your best approach is to use something like Cloudflare.
This compresses assets and places them up to distributed servers so ping times are smaller.
Caching is greatly improved.
You can get a free account.

Acorn

Acorn,

In your above description, you list a phone site and a mobile site. Is there a difference between mobile and phone or are you using these terms interchangeable?

Thanks
Ray

Quote:

---

Originally Posted by RKissane

Acorn,
In your above description, you list a phone site and a mobile site. Is there a difference between mobile and phone or are you using these terms interchangeable?
Thanks
Ray

---

Ray

const vnt = ['phone/', 'mobile/', 'tablet/', '']; //Subroot paths used; small to large
const breakpoint = [600, 840, 1200, 3600]; //each greater than or equal to Site Scale to fit width setting
const pagesize = [480, 720, 960, 1440]; //Site Page Size (Width), to determine Breakpoints

I have four connected websites, whose page widths are those in the pagesize array. The phone one is a Transitions site
The mobile is a Scrolling site
The Main and tablet are both conventional.

They are not Xara variants as I have JS code that detects the Breakpoints that I set and which switches accordingly between them.
I do not need to then have all four the same type and in the same design file.
I can change exactly where the breakpoints occurs and not rely on Xara's middling approach.

I tune the phone height to fit the phone screen so there is no scrolling.
On the mobile it scrolls page by page so each page's height is immaterial.

All use Scale to fit width.

The sizing and styling across all four is therefore totally flexible.
Each site also need not be a Xara one; it just needs to have the same page names.

The glue is a small 35-line JavaScript file.
It requires some work to handle Anchors in a Transitions site.
I am also scripting how to share resources across the sites, which is why I keep nagging Xara to sort out its buggy image filenaming feature.

Acorn

Thanks for that Acorn, I'll have a look at cloudflare.
I, like boy don't understand why these files don't negatively impact the Desktop scores?