I deployed a Nextjs app on Vercel. I found that the response time of the SSG pages with getStaticProps is slower in the first page load. The subsequent page load are instant. Why is this the case?
I expect that all page loads should be instant because they are cached in the CDN during build time. I am sure that the pages are SSG because I view them tagged as SSG in the build logs. What am I missing here? Thank you.
The static files are not in the CDN on first request after building.
Pull-based CDNs load the data on the first request and keep it around until it expires. Vercel handles most aspects of our infrastructure like a pull-based CDN
Source
The problem vercel server work like serverless if your website no one call him for a while Vercel will set your app to idle mode
Related
So I'm creating an application with next.js and want to use ISR on many pages. But the application has 2-3 API calls which are called from every page like header CMS content, footer CMS content and site configurations. So when the Next.js build is executed, these APIs will be invoked for every page being built as they are being invoked in the getStaticProps method of every page.
However, during the few mins of the build run, the API content is not expected to change much. Is there a way to call the API once, and use that response for every page during the build?
On the high level, I have a PWA with React frontend and .netcore backend. I use service worker for caching and offline ability, in conjunction with workbox plugins for some precaching feature.
The app uses Windows Authentication. Which works fine if it wasn't a PWA app. It also works fine the first time the PWA app launches, I get the username, password login popup.
However from the second time visiting the app, it wouldn't show the login popup, the app fails at pulling data from the backend because it is unauthenticated. One weird behavior is that, if I open Chrome Dev Tools(by F12), then the login popup immediately shows up.
I thought it's caching related and somehow the service worker interfered with the server side authentication workflow. Maybe because the index page is cached by the workbox precache plugins, and it did not cache with the fetch header of 'credentials': 'include'? I tried adding the fetch option to other api routes, which are cached by workbox plugin RegisterRoute. However I didn't find a way to add it to the precacheAndRoute(self.__WB__MANIFEST). Wondering if that's the problem. But I'm also not sure why having Dev Tools open would trigger the popup to display.
Any input is appreciated.
I have a Vue.js app and use Firebase Hosting to serve the static files to users.
Does Firebase Hosting have a method for putting the app into maintenance mode remotely? Without having to do firebase deploy
Maybe something that will allow me to redirect all the traffic to some other index.html, and be able to manage it from Firebase.
P.S. I've already looked into Firebase Remote Config (and it doesn't fit my use case, and their web related tools aren't fully implemented yet). And I'd like to avoid having a realtime database just for maintenance mode.
There is no mode-switch built into Firebase Hosting for temporarily serving other content.
But given the recent updates to deploy efficiency, it should be pretty low-cost to put up a temporary index.html while making the changes. Alternatively, you could deploy rules (in firebase.json) that temporarily redirect all traffic to a wip.html (for work-in-progress).
Which of these works best, depends on your current content structure. I.e. if you already redirect "all" traffic to index.html, I'd probably go with a rewriting solution.
You can also unroll your last deploy in one command.
Deploy maintenance page
Unroll when its done
Don't forget to send a 503 error for googlebot, asking it to come back in X hours.
We have our existing pages in ASPX and site is hosted on IIS7 server.
We are looking for revamping/design the pages in VUEJS 2.0.
We are able to get VueJS code integrated with existing ASPX pages by getting build.js generated (production) and referring the same on ASPX page and page will be having the Target element. This all is client side rendering.
Now, we want the same in SSR. That mean to be complete HTML code rendered on the page before being served to the client (browser).
This clearly indicates we need to setup NodeServer, which can be called up by ASP.NET to get the VUEJS code rendered and added on ASPX page before it's being served to the Client (Browser). Please correct me If I am wrong. Here we are looking for a dynamic webages (Not the static one with prerendering or static generation)
We have started looking up for NUXT.JS as one of the options. But this is recommended to be used for the apps hosted for NodeServer.
ref:https://github.com/MarkPieszak/aspnetcore-Vue-starter/issues/67
1: https://github.com/MarkPieszak/aspnetcore-Vue-starter/issues/67
Other big challenge going with Nuxt is, they are likely launching Nuxt2.js version, which may or may not have breaking changes. https://medium.com/nuxt/nuxt-2-is-coming-oh-yeah-212c1a9e1a67
Next option is to looking for following:
https://github.com/MarkPieszak/aspnetcore-Vue-starter
https://github.com/vuejs/vue-hackernews-2.0
http://mgyongyosi.com/2016/Vuejs-server-side-rendering-with-aspnet-core/
Above links mentions using ASP.net core API Microsoft.AspNetCore.SpaServices.Webpack.
I believe you must have faced this situation and reached to an optimal solution. I am looking for suggestions from veterans have achieved the same, what path to be followed?
IF this can be achieved at all? and what are the challenges I should look forward?
Thanks
I am deploying a PWA to firebase using the tutorial from the polymer project website. I have no issues deploying to firebase, but if I deploy a second time the new page does not load. It will load the old page until I clear the cookies. I see understand that the way a PWA site works is like an application where it stores parts in memory for faster load times. Is there a setting I need to change to make it load most recently deployed webpage? I appreciate all the help, thanks in advance!
You might be seeing an effect of your service worker. Try deleting the currently registered service worker from your browser so that the new one can take over.
In Chrome 51/52, open DevTools while on your site, and go to the Resources tab, and then Service Workers on the left panel. Click Delete to remove the service worker. You could also check the box for Update on reload, which allows you to update the service worker simply by refreshing the page.