This is the check list from Light house on my site.(made by GoogleSite)
Progressive Web App
These checks validate the aspects of a Progressive Web App, as specified by the baseline PWA Checklist.
1
Does not respond with a 200 when offline
2
User will not be prompted to Install the Web App
Failures: No manifest was fetched, Site does not register a service worker.
3
Does not register a service worker
4
Is not configured for a custom splash screen
Failures: No manifest was fetched.
5
Address bar does not match brand colors
Failures: No manifest was fetched, No `<meta name="theme-color">` tag found.
It looks like you haven’t created a manifest or any service workers: the key engine of PWA. Because of this you are not caching assets and they’re can’t be found online, so you can’t get a 200 status (all ok, page found).
From the question, I am assuming a simple static site. The simplest way you could solve this is by going to https://www.pwabuilder.com, imputing your website, and copying the boiler plate code. By the time you finish you will pass the Light House rest and your site will work offline and have all the PWA features.
Related
I have developed a web app that uses Nextjs app for the frontend and a Python (Django) API server as the backend. Most of my front-end pages have API calls to my backend server (in ComponentDidMount or in response to user actions like button clicks).
I want to deploy this app to my server. I am using Nginx as the reverse proxy. The backend deployment is sorted. I am confused about deploying the nextjs app.
After reading the docs I figured there are 2 ways to do this:
Run next build and then next start. This will start a nodejs server on port 3000. I can channel traffic to this port using Nginx.
Run next export. This will generate an out directory. I can channel incoming traffic to this directory using a reverse proxy like Nginx.
Which of the 2 options should I use? What are the differences?
Answering my own question with the help of the answer I received on the NextJS discussions forum link here
Basics of next build, start and export
next build builds the production application in the .next folder. You need to run this command irrespective of whether you want to run next start or next export.
After building, next start starts a Node.js server that supports hybrid pages, serving both statically generated and server-side rendered pages.
next export will export all your pages to static HTML files that you can serve with any host. This is similar to what create-react-app does, but you can still build dynamic pages at build-time with exportPathMap.
Note: Statically generated pages, using next export, are still reactive i.e. any dynamic JS code, which updates your pages at run time, will continue to run as usual (like any other ReactJS app). Next.js will hydrate your application client-side to give it full interactivity. Its just that the dynamic section of the page will only be rendered in the browser at run time and hence it won't be available to search engine crawlers.
When to use next export?
next export is recommended if you have some dynamic pages which need to some data to be fetched only at 'build' time. It is perfect for pages like landing pages, blogs, news articles etc, or for other kinds of pages which are updated only during code builds. You can setup a background task to build your code at regular intervals if your page data needs to be updated more frequently. This will speed up your 'first paint' speed and also provide the entire page data to search engine crawlers for indexing.
When to use next start?
If you do not need any data fetching at build time i.e. your pages are rendered dynamically at run time then you should use next build and then next start. This will also generate static HTML for sections of your page which are not dynamic. This will speed up the 'first paint' time of your pages. See this Automatic Static Optimization.
next export, also produces an optimized production ready build, but it builds fully static app, which means only html, css and javascript but no server-side code.
Since there is no server side code, you do not need a server to host your app. This makes hosting your app easier and cheaper because you dont need to maintain and scale a server. There are plenty of hosts in the market which offers very good pricing.
Since next export builds a static app, it means you cannot use api routes, server-side functions therefore you cannot revalidate. Revalidation means, your app will be checking database for a certain of time that you specify. Let's say you have a blogging app, you save your blog posts to database, with server side coe, you get those on server side, pass them to the client and client renders the posts and with revalidation option set, your app would automatically check the database if the content changed. Since you cannot use this feature, anytime content of your app changes, you have to redeploy your app.
My site works nicely as a PWA and I am trying to improve it. I have a couple of things going on and I am not sure if this is normal behavior or not.
Starting with offline.html. Right now I have a standard simple piece of text that say you are viewing example in offline mode. There is no header/footer or any other content. I'd really like to improve that but where and how much can I improve it? It doesn't seem to act like a normal page. I also find a problem on my child pages where when testing and looking at a waterfall chart, offline.html is coming back as a 404. I doubt this is normal.
Secondly, when I run a lighthouse test on a child page like example.com/childpage I get the following;
Current page does not respond with a 200 when offline
start_url does not respond with a 200 when offlineThe start_url did respond, but not via a service worker.
Does not register a service worker that controls page and start_url
I've tried to search for answers but I'm not having much luck. Any help or suggestions would be appreciated? Thanks.
I only understand from a VueJs perspective.
If your app isn't registering your service worker, then the service worker won't be able to intercept the http request, please see attached pic. basically you need to get that registered before you continue.
reference: https://www.sicara.ai/blog/2017-06-30-part-three-progressive-web-app-with-vue-js-webpack-material-design
you can add a <noscript> tag into your index.html which will catch when your JS doesn't load see: https://web.dev/without-javascript/
Going back to registering your service worker; You need to make sure your webpack, or like in my case my vue.config.js is actually registering your PWA correctly, including the service-worker.js
pwa: {
themeColor: '#2F1B55',
msTileColor: '#000000',
iconPaths: {
favicon32: 'static/favicon-32x32.png',
},
workboxPluginMode: 'InjectManifest',
workboxOptions: {
swSrc: 'service-worker.js',
},
navigateFallback: 'yourDir/public/index.html'
}
navigateFallback this is important to tell the browser where to start the JS from again when it falls over mid app.
Getting a service worker registered on build is your primary concern. Try reading the article from 1. to get a greater understanding.
Thanks for your input, I'll read tonight. That said,I can put my mobile device into airplane mode and my entire PWA acts just the way it did when I was online (unless its a DB lookup). This is why I'm a bit confused. Every page that I visited online is available offline. I only get these warnings from lighthouse. In devtools, there is no warning. Cheers.
With the Ionic 4 framework and using the PWA.
I would like all the pages, the whole project is cached as soon as the first page is loaded.
In fact, I would like the user to log in once and then offline to access all pages.
Because currently, only the first page is displayed ..
You are talking about "multiple pages" in a sense that is implying that your implementation does not use the App Shell model.
Probably, you need to do the following things:
Implement the App Shell
Implement navigation between the different content pages of your app
Implement the static content pages (I assume they are static, since you want to primarily use them offline)
Have the service worker cache the whole bunch.
All the content is now cached on first launch. Dynamic content fetched from the server would of course still require an internet connection.
I'm developing an offline web-app for a client of ours, designed to run on an iPad in airplane mode, mounted on a stand. It has no server-side dynamic pages, only a static HTML page, many JavaScript components to handle navigation and interactivity, and a bunch of small graphics assets. The whole website (static html + css + js + graphics) weighs exactly 8.3Mb.
I'm caching the whole site via an offline.manifest declared in my single HTML file, this manifest references absolutely all the files under the root directory, so that all files needed are cached.
I'm not using localStorage, IndexedDB or other offline-storage techs in my JS code. Apart from the "automatic" caching, I don't store anything on-device.
So atfer checking my webserver logs, when my client installs the webapp on its iPad homescreen, it downloads all the files once, then never downloads anything from my server afterwards. That's fine, exactly what he wanted in the first place : a full offline webapp.
Then, how comes that after several minutes of testing from my client, his iPad asks him to “increase local storage from 10Mb to 25Mb” ???
FYI, the app consists of a kind of quizz: one welcome screen, 19 question screens, one result screen ; the user can navigate backwards/forwards in the questions sequence, but they're created and nullified on-the-fly so as to minimize memory footprint. Anyway I don't believe this problem has to do with RAM access, only with "hard", permanent, cached storage.
I've noticed that with all apps, it's like the iPad has to realize it has everything, and waits a few seconds to realize that it's going to go over it's app limit.
it would be nice to have it default to a larger amount, or let you set it up with a larger amount to begin with.
Seems like my client doesn't have this problem anymore. As I'm not in direct, physical contact with him, I can't tell what he did to get rid of it.
I am trying to build an iPhone web application using ASP.NET. The page is dynamically rendered once for each visitor. At this point the page can be bookmarked and it will never change again for that visitor. For this reason it should be cached locally from that point on so the application will run if referenced from the bookmark even if no network connection is available. No matter what I try the phone continues to request the page from the server forcing a re-render or it fails if the phone is offline.
Louis Gerbarg suggested in this post that I use HTML5 Cache Manifest to get this working however following the w3.org docs does not appear to work for the iPhone. Does anyone have a good example where application cache is working?
The cache manifest file has to be served with a 'text/cache-manifest' mime-type. This is absolutely critical, it will not work without it. If you navigate to the url of your manifest file, it should trigger a download...
Also, I've found that putting the manifest location in the tag as an absolute location, as well as all the entries in the manifest file to be more effective.
I answered your previous question related to this, but it was not clear from that question that you were trying to cache dynamic content. The cache manifest is for getting static content you want for offline web apps to work.
I am not sure you can do what you want. Do you want the app to be able to function offline, or are you just trying to peg something in the cache because it is slow to download? Unless you are actually constructing an offline webapp (which the user will add to as a bookmark or an app in the Spring Board) then your page can (and must necessarily) be evicted from local storage at the browsers discretion, regardless of how loose a cache policy you set on the page.
You should use the Safari Javascript Database API which should work for iPhone and Safari 3.1. It works great for local caching and data storage:
http://developer.apple.com/documentation/iPhone/Conceptual/SafariJSDatabaseGuide/
It could be to do with the size of the output.
I can't talk from any serious experience in tweaking things specifically for an iphone, but there is an intersting read from the YUI team here: http://yuiblog.com/blog/2008/02/06/iphone-cacheability/, which indicates that the largest unzipped cache file that can be held in an iphone is 25k, and that for optimal caching, as many components as possible should be <25k.
That may be the cause of your problems, but that's only a guess.