Avada Forums Community Forum PWA – Support for HTML file types in Cache-First strategy setting

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • marklchaves
    Participant
    Post count: 873

    Hi Everyone,

    I’ve searched on this topic without any luck. Does anyone know when there will be support for offline Avada WordPress pages using PWA plugin with Avada?

    If so, a link to the future release documentation would be appreciated!

    Thanks for your time,
    mark

    serhumano89-2
    Participant
    Post count: 1

    So, if I understand correctly with the current PWA plugin is not possible to run a PWA offline? Isn’t that the purpose of having a PWA?

    Aristeides
    Spectator
    Post count: 23

    Hello there!
    I wanted to provide some insights as to why currently offline-browsing of a site is not implemented.

    Yes, one of the things that Progressive Web Apps can do in general is allow a site to be browsed offline. However that’s just one of the many things that PWAs can do, it’s not the only thing.
    A limitation of PWAs is that there can only be 1 service-worker present on a site. That means that if a plugin adds a service-worker and then another plugin adds another, and then the theme adds another, only one of them will work.
    In order to be compliant with the future of WordPress and what wp-core plans to do with PWAs we decided to use the official PWA plugin: https://wordpress.org/plugins/pwa/
    That plugin adds an API allowing all 3rd-party plugins and themes to hook in some standard actions & filters, so everything gets added to the same service-worker and is guaranteed that there be no conflicts between them in the future.

    The PWA plugin currently does not support offline browsing. It supports adding a custom template that can be shown when users are offline, but not actual offline mode.

    As soon as support for offline-mode gets added to the plugin Avada will also add support for it, but at the moment this is all that is supported: https://github.com/xwp/pwa-wp#offline–500-error-handling

    To answer the question:
    Would it be possible to add offline-browsing to Avada? Yes, it would be possible. In fact our first implementation was completely custom and supported ofline browsing. We simply ended up not using it or shipping it in the theme because it was not as robust as the official plugin’s implementation, it was not future-proof and was prone to conflicts with plugins that were also attempting to add service-worker implementations.
    Offline-browsing is just one of the many benefits that a PWA has to offer. When the official plugin supports it, so will Avada.

    For documentation etc you can check out the github repository of the plugin: https://github.com/xwp/pwa-wp
    You can add issues there if necessary, request this feature and join the discussion in the plugin’s issues.

    I hope that sheds some light here. 🙂

    marklchaves
    Participant
    Post count: 873

    Hello @Aristeides,

    Thanks for your informative reply. Yes, I’m familiar with the current architecture limitations, and I also follow threads on https://wordpress.org/support/plugin/pwa/.

    I appreciate you sharing your insight and Avada’s history with off-line browsing.

    Enjoy,
    mark

    Jetxpert-Envato
    Blocked
    Post count: 339

    All,

    Personally, I do not see the benefits of PWA (technology nor plugin) at this time. If someone here does, please share.

    This great article sums up why: PWAs Won’t Save Mobile WordPress Speed

    Last, I’m interested in knowing why is Theme-Fusion (Avada) suggesting the use of the PWA plugin (through its repository) when it’s still in “beta-testing” mode and causing issues? Click here for details.

    Cheers!

    Aristeides
    Spectator
    Post count: 23

    Personally, I do not see the benefits of PWA (technology nor plugin) at this time. If someone here does, please share.

    This great article sums up why: PWAs Won’t Save Mobile WordPress Speed

    In its current form the benefit is a lot more aggressive caching. Assets cached via the PWA don’t even make a request to your server. Instead, the browser intercepts the request before that and serves the cached assets immediately.
    That improves the load speed of pages a lot! Also keep in mind that the benefits also become evident for users that visit more than one pages on your site. And it’s not just for mobile browsers, it’s for desktop too. The 1st pageload will be identical to what it would be without the PWA, however any subsequent visits to your website by the same user are faster because of that extra cache. So if you’ve already seen a page on your browser, the 2nd page-load will only get the HTML of the document, and any new images that may exist. The result is faster load times for repeat visitors and less data downloaded – which is important because data on mobile costs a lot in some countries.

    That fact that someone wrote an article and put it online doesn’t necessarily make it true. It’s someone’s opinion and nothing more than that – and more importantly it’s full of half-truths. For example Safari doesn’t account for “Fifty percent of mobile browsing”, it never did. Right now it’s at 20% (see stats on https://gs.statcounter.com/browser-market-share/mobile/worldwide). On desktop it’s at 5.8% – almost half of Firefox’s market share.

    PWAs can be bad, or they can be good. It depends on how they are implemented.

    Last, I’m interested in knowing why is Theme-Fusion (Avada) suggesting the use of the PWA plugin (through its repository) when it’s still in “beta-testing” mode and causing issues? Click here for details.

    We chose this plugin because it is the official plugin for PWAs in WordPress. It is built by Google, Automattic and developers from XWP. That plugin offers an API for plugin and theme developers to use. It is a framework and there are discussions to put it in WordPress-Core at some point. So there really was no question about which solution/plugin we should support… If we want to be future-proof this is the way to go.
    Also it is not on “beta-testing” mode, its beta phase finished months ago.
    As for the issues in the plugin’s page on wordpress.org, 22 issues in more that a year is not a lot of issues… there’s a single page of issues on that plugin. Yoast SEO’s support page on w.org currently has 729 pages of issues, each page holding 30 issues. That doesn’t make it a bad plugin.

    That plugin and PWAs in general are at their infancy. Yes, there’s room for improvement. And they will get improved in time. They’re not perfect, nothing is. They are simply a step in the right direction.

    Jetxpert-Envato
    Blocked
    Post count: 339

    @ Aristeides,

    Thank you so much for your feedback. Extremely valuable!

    Final Comments/Questions:

    (1) The article provided above is only a sample of many that argue the benefits of PWA.

    (2) The PWA vs. Yoast SEO comparison is not a good one. If you do the math and normalize the data, Yoast SEO has exhibited — so far — less issues than PWA. Issues/Download Reported —> PWA = 2e-5 | Yoast SEO = 3e-7

    BTW, Yoast SEO only has 49 pages of issues, not 729.

    (3) Apparently, there are no rules or requirements from WordPress for plugin software versioning, but since PWA is considered stable (and released), shouldn’t it be at 1.0? Traditionally, anything below 1.0 is considered “alpha,” “beta,” or “unstable.” Great explanation here: https://en.wikipedia.org/wiki/Software_versioning#Pre-release_versions. I know, a question for the PWA plugin developer; however, your input is appreciated.

    Again, thank you.

    Aristeides
    Spectator
    Post count: 23

    Regarding Yoast SEO you’re absolutely right, it was a bad example. I don’t know where I saw the 729 pages, either I had a dozen tabs open on my browser and got confused with something else I was looking at (not at all unlikely) or I need to check my eyes 😀

    The versioning system is a bit weird… Traditionally it is recommended that developers follow semantic versioning however not everyone follows that.
    The PWA plugin was in beta until April, and until then when users were installing the plugin from Avada they were actually getting a customized version we were maintaining instead of the version from the repository. Our version contained bugfixes and our own contributions to the plugin – which eventually all made it in the current stable release of the plugin.
    Considering that the plugin was in testing mode until April 16 (it wasn’t even beta, it was an alpha release), the number of issues reported is understandable.

    My assumption is that the developers of the PWA plugin will release v1.0 when they consider it feature-rich and complete, supporting all the goodies that PWAs have to offer. But that’s just a personal assumption based on what I did in the past for my own plugins on w.org

    As for the fact that many argue the benefits of PWAs, that is to be expected. It’s a relatively new technology and just like anything else new on the web there are those that love it, those that hate it, and some that find it useless. It’s just human nature 🙂

    marklchaves
    Participant
    Post count: 873

    Hi @Jetxpert-Envato,

    I read the article you supplied above.

    http://pagepipe.com/progressive-web-apps-pwa-wont-save-mobile-wordpress-speed/

    This great article sums up why: PWAs Won’t Save Mobile WordPress Speed ~JE

    I disagree with what you say regarding the quality of the article. But, I’m not saying that PWAs are supposed to “save” anything. The PWA is just another platform. Another framework. Use it or don’t.

    That fact that someone wrote an article and put it online doesn’t necessarily make it true. It’s someone’s opinion and nothing more than that – and more importantly it’s full of half-truths. ~A

    Agreed. The piece (actually the blog in general) needs a proficient staff editor and some basic fact checking.

    Examples

    PWAs consume about 50MB of available space. It consumes the user’s bandwidth. And Apple purges the PWA from cache after two weeks. ~ST

    Citation needed.

    PWAs are currently not supported by Safari on iOS. Fifty percent of mobile browsing is on Safari. ~ST

    Incorrect. I’ve been able to install PWAs on Safari iOS since when I first started this thread (June 2019). According to CanIUse, there’s been Safari iOS support since March 2018. Citation https://caniuse.com/#feat=web-app-manifest.

    You can see screen grabs of this from my latest PWA project here https://github.com/marklchaves/ini-bali/blob/master/README.md

    Their (PWA) main goal is converting loser and drowning apps to web pages. ~ST

    Citation needed.

    And PWAs waste energy and resources. Period. ~ST

    Speculation (broad generalisation). It always depends on the requirements, use case, and as @Aristeides aptly put, the implementation.

    Another Post on Same Blog just for Grins

    http://pagepipe.com/divi-theme-sucks-and-other-popular-paid-themes-are-slow-too/

    We analyzed every one of the 117 themes written by Automatic. Inc. That’s WordPress’ parent company. ~ST

    Incorrectly spelled. Should be Automattic (https://automattic.com/). Citation to the analysis also needed.

    Hi @serhumano89-2,

    So, if I understand correctly with the current PWA plugin is not possible to run a PWA offline? Isn’t that the purpose of having a PWA? ~S

    Sorry for the late reply. I wanted to perform my own tests before responding to your good question. I drank the PWA Kool-Aid for the caching. Just as @Aristeides mentioned earlier. Their caching strategy (from reading their docs) was the first thing that caught my attention. Offline support is icing on the cake to me. And, may not be well suited for every case (as usual).

    If you want a visual of what I perceive to be valuable browser caching benefits, see my results here https://github.com/marklchaves/ini-bali/blob/master/README.md

    Lastly — All I Really Wanted to Do Months Ago

    The code snippets below are all I was asking for in my original post way back when. I.e. where the magic happens. Now, I can do them freely, any time, and with ease — outside of WordPress of course.

    Pre-cache my Static Files (e.g. images, icons, and offline message)

    `
    module.exports = {
    “globDirectory”: “./”,
    “globPatterns”: [
    “assets/**.*”,
    “icons/**.*”,
    “bookend.json”,
    “offline.html”
    ],
    “swSrc”: “src/sw.js”,
    “swDest”: “sw.js”,
    “globIgnores”: [
    “./workbox-config.js”
    ]
    };
    `

    Cache my Dynamic Content

    `
    workbox.routing.registerRoute(/(index|\/articles\/)(.*)html|(.*)\/$/, args => {
    return workbox.strategies.networkFirst().handle(args).then(response => {
    if (!response) {
    return caches.match(‘offline.html’);
    }
    return response;
    });
    });

    `

    marklchaves
    Participant
    Post count: 873

    Sorry. Re-posting the code snippets. I forgot to convert my original GitHub style markdown.

    Pre-cache my Static Files (e.g. images, icons, and offline message)

    
    module.exports = {
      "globDirectory": "./",
      "globPatterns": [
        "assets/**.*",
        "icons/**.*",
        "bookend.json",
        "offline.html"
      ],
      "swSrc": "src/sw.js",
      "swDest": "sw.js",
      "globIgnores": [
        "./workbox-config.js"
      ]
    };
    

    Cache my Dynamic Content

    
    workbox.routing.registerRoute(/(index|\/articles\/)(.*)html|(.*)\/$/, args => {
      return workbox.strategies.networkFirst().handle(args).then(response => {
        if (!response) {
          return caches.match('offline.html');
        }
        return response;
      });
    });
    
Viewing 10 posts - 1 through 10 (of 10 total)
  • You must be logged in to reply to this topic.