I'd rather have the site not annoy visitors than to pass a silly test.
MOST web sites are over-loaded with fluff like social-media controls, zillions of redundant tracking scripts, fail to combine CSS and JS and so load dozens of CSS/JS files etc. etc. etc. such that there are plenty of ways to improve load speed that are much more important than this.
As well, bear in mind that JQM is an early form of a SPA (Single Page Application) and as such the delay occurs only on the very first page loaded. (Assuming the site was built correctly and doesn't use data-ajax="false" or rel="external" when loading pages.) On subsequent page loads, there is no loading of CSS or JS at all (unless there is some page-specific JS).
Contrast this to a conventional website, where all CSS and JS used in a page has to be loaded with each and every page.
JQM is "heavier" than a more conventional site for the first page, as both CSS and JS are large, but at the same time, is MUCH lighter than most sites on additional page loads.
Finally, all of these page-speed rules are just somebody's opinion and there are tradeoffs (such as nasty visual effects if you truly want "fastest".)
Once other issues which are much lower-hanging fruit are dealt with, one could take a guess at what part of the first page is "above the fold" and play some tricks with the first page. But is it worth it? In most cases, I think not.
If that's your site, now I'm confused - because that site doesn't use jQuery Mobile.
Are you considering rewriting your site using jQuery Mobile?
As far as the example sites you gave, I visited them, and none of them use jQuery Mobile either. In fact, the third one isn't even a live website - it lands on a "domain for sale" page.
Where did you get the idea that these sites use jQuery Mobile? Did you look at the document sources? If you had, you would have seen that none of them load jQuery Mobile. BTW, I did examine them in an iPhone simulator, just to make sure that they weren't using JQM only on mobile devices and not desktop browsers.
(I did not examine anything from your list of "suspected jQuery Mobile sites").
I think you need to visit some SEO forum, where they worry about such things. I'm pretty sure, though, that - while considered - page load speed is a only small component of search engine rankings.
BTW, nobody here on this forum (or, certainly HARDLY anybody) are developers of jQuery Mobile or jQuery. (You might occasionally find a JQ developer in the "Developing jQuery" form.) We are just all developers like yourself helping each other out. I am not here to defend JQM.
Frankly, you will be hard-pressed to find major sites using current jQuery Mobile. I think with the non-progress of JQM and the light speed at which major sites operate, most have moved on to other solutions.
But I suggest you go find them and test them yourself. I don't know how you force Google PageSpeed Insights to use a specific browser identity. As many sites that do use JQM use it only for mobile devices, and so if you test without the right browser identity, you will just be testing the non-JQM version of the site.
I looked through the JQM "gallery" and did find one site there still using JQM, but only for mobile devices. That's Lending Tree. It looks fairly non-bloated. However, it uses a quite old version of jQuery Mobile. I can't actually tell what version, it seems a custom build, from 2013. You would have to look up the commit ID on GitHub to see what version it is. Anyway - although it does not use current jQuery Mobile, it is a starting point that might give you an idea of performance.
I'm not going to spend more time investigating - that's YOUR job - I'm just giving you some ideas. I do not currently use jQuery Mobile, but may in the future if/when 1.5 is released. And I only have used it in the past in hybrid mobile apps, and so these kind of performance considerations have always been a non-issue in my own work. Search engines don't search native apps. And there is no performance issue at all when loading pages from the local filesystem on the device. I don't have any experience using JQM on websites.
Yes, this the the JQM support forum provided by the developers.
It is very slow here. JQM's last update - 1.4.5 - was in late 2014. And that was just a maintenance release. The last major update - 1.4 - was in December, 2013.
It hasn't kept up with the latest browser releases, and I'd guess that many who have used JQM in the past - like myself - no longer actively use it.
1.5 just went into alpha test, so perhaps usage will increase in the future.
I answer questions when I see them because I've used it extensively in the past, and authored a popular third-party plugin. There aren't many questions, and so I answer them when I see them.
I have never used JQM on a website. But have used it extensively in hybrid mobile apps. So, I have a blind spot about web page load times. It's just not an issue I've faced. If you wait long enough, somebody will come along who has dealt with web page load times.
Once again, the sites that you cited have huge page load problems that should be solved long before "blocking CSS" needs to be addressed!
The developers generally do not participate in the forums here. They are too busy working on new versions.
Maybe Jake will share URLs of some of his JQM websites. If you test them with Google's tools, it should give you a good idea of how a WELL-WRITTEN JQM site can perform!
You provided several examples of bloated sites from print publications. It is my observation that many/most such sites are among the worst at page load efficiency. They are loaded-up with redundant scripts and ads and silly effects, and often make no effort to combine and compress scripts and stylesheets. They are, sadly, not good examples of well-written websites.
I just checked some old HTML JQM sites of mine, for mobile they come up in the 60s. I’ve looked at their insights before, and used some of their advice. But, since most of the Internet is full of pages with much worse scores, I don’t care about the score.
I doubt you could make a proper JQM site without the fold problem. I guess I could load all the scripts asynchronously, then deal with the problem of them coming in in the wrong order. I doubt it is worth the trouble.
I could also combine all the scripts, and load it asynchronously, but that would skip the cache, and would be worse for the user, but better for the insights.
In my experience (I've owned an SEO consulting company) it's worth it but only if SEO is important. For a single-group musical band site SEO has little value.
Our issue is jquery.min.js (see dev link below) - page doesn't render if we load it async. That's the fix we're wanting.
JakeCigar: Just noticed - your above-the-fold-issue is CSS, not JS!! Nice! That likely is a quick fix but I'm stabbing in the dark. I'm looking into how you got around the JS issue... Thanks again for the post.
jQuery Mobile is a plugin for jQuery. jQuery HAS to be loaded first. You cannot load asynchronously in haphazard order.
If you combine and minify your scripts, it is a non-issue. You will wind-up with ONE script file. And making ONE script file and ONE CSS file is a good first step for good performance.
Asynchronous loading might be useful for a large, bloated site. But the biggest problem for large, bloated sites is that they are large, bloated sites.
You can build custom jQuery Mobile with only the features you want. This will help as well.
I thought what we were talking about here is above-the-fold CSS. Sorry if I misinterpreted. If you defer loading CSS, that will cause the FOUC issue. But, as well, if you allow the page to render before JQM initializes the page, you will have a similar issue with ugly re-rendering.
Wow, Server Worker, never heard of this. Don't want to do browser-by-browser fixes, not scaleable - but if it's universal & mobile-browser-supported, I'm all for it. Will read up. Thanks for the education ;-).
No, combining scripts and styles will not pass the above-the-fold test. But it will certainly improve overall performance vs loading a handful or a dozen or a hundred scripts and styles separately.
What is a "non-issue" is random script-loading order. If you combine and minify, then your scripts always load in the order in which you want, and without multiple requests. There is a tradeoff you will have to consider vs loading popular scripts from a CDN. If your site has poor bandwidth or is far from your users, it might not be the best approach. You should at least combine/minify your OWN custom JS and CSS, though.
Async loading IMO is a band-aid for sites that insist on continuing to be bloated. So, they can load what is important first, and then load the bloat later. But I hate the result, which is stuff moving around on the page while I am trying to read something.
The way to pass that test is to not load any synchronous scripts or styles until after the fold. Years ago it was common advice to load scripts and styles at the bottom of the document. Most have long ago abandoned that practice, as browser and network performance have improved drastically.
If you want to pass that test, you are barking up the wrong tree with JQM. I think you are needlessly obsessing on a single performance test. That test is really only passable by hand-crafted sites that do not use large JS or CSS frameworks like JQM.
Finally, like I said, I am not here to defend JQM. In fact, my advice currently is not to use it for new sites. When 1.5 is released, I will review my advice.
Given improvements in cross-browser compatibility, powerful new CSS3 features, and adopted HTML5 features, there is a significant move afoot to ditch both jQuery and frameworks, and work closer to the metal. If you are going to obsess about SEO, that is the way to go today.
Bootstrap is popular (extremely popular, actually) and lightweight. And Bootstrap 4 will be released soon. I would myself take a chance on Bootstrap 4. It has many advantages over 3.
It is not a SPA framework like JQM. Just simple one-document, one-page.
I use Bootstrap 3 in my current work, but it is by client's choice. I do some Ajax "pages" that work similarly to JQM with my own custom code.
I work on mobile enterprise apps, and my goal is for a page to load in less than 50mSec i.e. 1/20 of a second. (This is from local device sandbox filesystem, not the Internet.) At 50mSec, it will feel "instantaneous" to the user, as this is at the edge of human perception. I have achieved that with JQM in the past, by avoiding some of the slower JQM functionality. For example, i never use listviews. It is easy enough to use a simple HTML list structure and your own flexbox CSS. It is at least 10 times as fast as JQM listview.
In mobile enterprise apps, nobody cares about fancy effects. The app is to get a job done. The less of employee's time you waste with silly effects, the better. That said, I use some CSS3 effects when the usefully add to the UX (by providing feedback) while not getting in the way.
I like Framework7 and want to try it some day. But it is not suitable for websites. It is designed specifically for mobile hybrid apps, and so it only supports iOS and Android browsers. It is very similar in concept to JQM, though! The only thing I don't like about it is that it uses Less for CSS. I much prefer Sass. I don't know why they made that unpopular choice. But I could live with that.