using the most current version of Vue Cli 3 and the PWA feature enabled, I have noticed that our PWA is starting/booting way faster when the client is offline vs online. I was thinking that a internet connection could never slow down the boot time, as the service-worker would always first serve cached files and afterwards check for updates. For me, it is not obvious which default caching strategy for Workbox is implemented by the Vue Cli 3. The practical problem is, that none of our customers is turning on "offline/flight mode" on their phones, instead they just suffer from poor internet connection and thereby do not benefit from the offline capabilities of our App. It seems that the service-worker is not serving cached files unless the client is completely "offline". Boot times therefore are horrible...
Help very much appreciated.
Related
I'm trying to build a Vue web app and a friend was using it when it froze. Refreshing the page or opening a new tab and going to the page didn't fix it, and it would just keep loading until chrome said the page was unresponsive.
I thought it might be a network issue on their side but it works fine on their phone. Then I thought maybe there was a localStorage or cookie corruption issue, but then it was still broken on a different browser(chrome & edge).
https://i.stack.imgur.com/CTLTs.png
https://i.stack.imgur.com/zbjdr.png
This site doesn't seem to show any HTML and upon reload, nothing pops up in the network tab.
https://i.stack.imgur.com/zjqrk.png
The site uses vue3, vuex, fullcalendar, fontawesome, lzutf8(compression algorithm package). It's hosted on netlify.
Honestly, I don't even know where to start debugging this since I can't reproduce the issue on my computer and it makes it worse than I don't physically have the laptop in front of me. Here are some issues I think it may be:
There is some corrupt data between chrome and edge that's causing the site to freeze
I'm using a compression algorithm package to compress the vue store into a copy/pastable string. It's possible this is causing the site to slow when vuex tries to load the getter for the compressed store, but if the localstorage is empty all it has to compress is empty arrays so I don't see how compression would cause an issue.
A firewall on the device could be blocking the website
Maybe there's a chance Netlify could be blocking the site?
Potentially there's some issue with vue or vuex that I don't know about?
Here's the github repo: https://github.com/ZombiMigz/cpp-scheduler-webapp
and the website is deployed here: https://cppscheduler.com/
Any help or ideas would be greatly appreciated
I've built multiple sites with Nuxt SSR, but never touched the static part.
As far as I know, upon build-time, Nuxt automatically executes all API calls and caches them.
If I want to make a blog with a static Nuxt site, how would I update the content? Is it only possible when I rebuild the app?
Seems unnecessary to rebuild everything every time I add a new blog post. With SSR I just reload the page.
Also wanted to note that I have a Strapi.js backend running on a VPS and I usually make changes weekly. Nuxt's docs state that I need to push my changes to the main repo branch but there's no changes on the frontend.
Does this also mean that the headless cms should be local only?
The whole point of having a static build is to have all the generated files with no additional server Node.js server needed. It reduces heavily the costs, removes a point of failure, discard any notion of server charge (amount of users at the same time on your app) and probably some other advantages yeah.
Downside, you indeed need to actually yarn generate the whole app again if it's something that was added/changed in the codebase. Usually it's pretty fast and there are also incremental builds if I do remember properly (you will not regenerate all the 99 old blog posts but only the 100th, the new one).
Headless CMS like Strapi usually work with a webhook: you add a new CMS article or alike, Strapi will notify your JAMstack platform to rebuild your app. Even if no front-end code was changed, you can force to build it with the new data coming from the headless CMS' API.
I've built a Microsoft Teams channel tab with SSO and I'm hosting the tab application which I've built with React via create-react-app.
The auth works well, and the app loads and runs.
But when I update my app on the web site, the Teams desktop client (Mac and PC) will sometimes cache the old app and will not pick up the changes. But then sometimes it will.
If I run the web client, it usually picks up the changes.
I've verified that I'm serving up new bundles with different names each time I update. But running the Teams desktop devtools I can see that Teams is asking for the old bundle, every time, so it's definitely caching the response from my app's URL.
I've read about the problems people have with the Teams desktop client has with caching Sharepoint content and not picking up content changes. I've tried the cache clearing techniques but they don't seem to work for this issue. And I can't reasonably have users do crazy cache clearing every time I make an update to the tab app.
What should I do? Some have suggested I need to update my version in the app manifest and redeploy to Teams -- that seems really brutal. Do I need to set some cache headers in a certain way to force the Teams client to pick up the new code?
Solution
Set a Cache-Control response header to no-cache (or must-revalidate) for your build/index.html.
Explanation
We had the exact same issue. Turns out it was because we cached our build/index.html.
According to the create-react-app doc, only the content of build/static/ can safely be cached, meaning build/index.html shouldn't be cached.
Why? Because files in build/static/ have a uniquely hashed name and are therefore cache busted on deployment. index.html is not.
What's happening is since Teams uses your old index.html, it tries to load the old /static/js/main.[hash].js defined in it, instead of your new JS bundle.
It works properly in the Teams web client because most browsers send a Cache-Control: max-age=0 request header when requesting your index.html, ignoring any cache set for the file. Teams desktop doesn't as of today.
This seems like an issue with the way your app is managing the default browser caching logic. Are service workers enabled for your app? What cache control headers is your web server returning?
There are some great articles that describe all the cache controls available to you; for example:
https://medium.com/#codebyamir/a-web-developers-guide-to-browser-caching-cc41f3b73e7c
Have you tried doing something like this to prevent caching of your page (do note that long term you might want to use something like ETags which is a more performant option):
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#preventing_caching
P.S. You can also follow the instructions here to open the dev tools in the Desktop Client to debug all this:
(How) can I open the dev tools in the Microsoft Teams desktop client?
And even force clear any cached data/resources for your app:
I have a VueJS application that is deployed to a local IIS 10 server for intranet use.
Trouble is, the index.html file is getting cached and a forced, manual clearing of the browser is needed to see updates. I understand there are ways on the server side to prevent this, but I'm unclear based on what I've read so far as to what the proper way of making sure the html file isn't cached is (js, css and the like are, of course, not cached since they have the additional value appended to the file name during build.)
I'm very much a novice when it comes to the server side of things, so any insight would be greatly appreciated. Thanks!
Which packaging tool do you use in your project? Generally speaking, Webpack/Vue-CLI has settings for prevent the file from caching in the browser on the client-side. In other words, it adds hash value to output files which could flag the version we build recently, this will result in the client browser to forcibly request the new version file.
In the Webpack.config.js
output: {
filename: '[name].[contenthash].bundle.js'
}
https://webpack.js.org/guides/caching/
See these links for more details.
Browser cache problems with webpack chunks and vue.js components
how to force clearing cache in chrome when release new Vue app version
VueJS/browser caching production builds
When I build the production build, the size of the css+js is going up to 3.8MB.
The only thing I could see is bootstrap which is taking half of the size amongst 3.8MB.
The app contains CRUD functionality in admin module where I have used bootstrap mostly and the other module is a list of static pages wherein I have used only grid of bootstrap.
Kindly guide on How can I make improvement in optimizing this further?
This is expected and using bootstrap and there's nothing you can do. If you had, instead, used bootstrap-vue you could import only the specific parts of the modules that you need (javascript) and that would significantly reduce the size of your bundle.
With that said, there's nothing wrong here. The gzip size of these is 252kb at maximum and that's quite cheap.
If you serve your site using http2 and the browser supports it, your request will be multiplexed and will use TCP pipelines to load the assets. This has huge gains and improvements over HTTP1 in that:
the connection to your server is opened through a TCP socket
the TCP socket then balances the requests by using Frames (which are asynchronous) vs http1 which is synchronous and could only manage 2 synchronous HTTPD threads at a time
the pipeline does not wait for assets and continues to cascade requests for assets, which improves the page load vastly.
So to summarize - serve your assets gzipped and make sure your web server uses http2 and your issue is trivial at this time.
Consider using purgecss plugin to get rid of all unused bootstrap classes: https://www.purgecss.com/guides/vue