We are using Framework7 (version 1.6) in combination with React, Redux & Cordova in order to build an app that should be made available in the App & Play Store soon.
The app has about 15 different pages which primarily show textual data. Graphically speaking, the app is not very complicated.
When we start the mobile app, the application is very responsive and feels native. However, after navigating between different pages (± 30 times), or after recovering the app from an idle state we notice that the performance of the app degenerates remarkably. We have reason to believe that this has to do with the way framework7 caches the pages. When we look at the DOM structure of the web application, we see that when changing pages, the old page remains in the DOM and gets the css class cached. Also when putting breakpoints in the react components representing the pages, we see that these pages remain active. In other words, when you visit a page 20 times, 20 instances of the pages will be created and any handlers (like reacts componentwillreceiveprops method) keep getting called for each one of these instances.
We currently think these pages that are not cleaned up are causing the performance degradation, so we have been trying to configure the framework7app such that this caching behaviour is prevented.
We have been trying multiple things to prevent this cachingbehaviour:
1. we've put cacheDuration to 0, preloadPreviousPage and cache to false in the framework7App configuration.
=> this does not prevent any of the caching behaviour
2. we've put domCache of the pages to false
=> this breaks the navigation. Once you navigate to a page you already visited, the app doesn't navigate to the page anymore.
3. We have even been trying to do any cleanup ourselves, based on methods that are used internally in the framework7 library. This is one of the methods we came up with in an effort to clean up these pages:
setTimeout(() => {
var allPages = $(f7.mainView.pagesContainer).children('.page.cached');
for (var i = 0; i < allPages.length-2; i++) {
f7.pageRemoveCallback(f7.mainView, allPages[i], 'left');
f7.router._remove(allPages[i]);
f7.mainView.allowPageChange = true;
}
}, 200);
=> This does clean up the containers properly and removes the cached pages from the DOM, but whenever this code has fired once, the performance of the app deteroriates tremendously and does not get better after a while, even when the performance was still acceptable before cleaning up the cache. Could you please tell us what we are doing wrong?
Can somebody give us some insights on what we might be doing wrong and if this behaviour is normal? Thanks!
Related
I've been reading about lazily loading code in react.
With lazy loading, only the needed code will be loaded and doing so,
your initial loading will be faster (because you will load much less
code) and your overall speed will be much faster being on demand.
This is what I've understood.
In a single page application, the entire page is loaded onto the browser initially. We use module bundlers like webpack to bundle the application into a single page. Everything's great.
Now, if the application size is large, the load time would increase. To improve performance, we can divide the bundle into separate chunks that will be loaded only when needed.
My question is, if we have to divide our page into chunks, is it still a single page application because the browser will have to request the server for these chunks whenever they are needed? I feel like there's a gap in my knowledge and I don't know what's missing.
The traditional web applications used to work with postbacks to the server to fetch HTML to render a new page. Then AJAX came into the picture and applications were able to render data asynchronously thereby making sure that the user doesn't need to wait the time when the browser would refresh on postback to render the new page.
Modern Javascript libraries like angular, react etc. bring single-page application (SPA) model which runs inside a single page without requiring the browser to reload as the user navigates the site (ie. with only a single container page for entire application,like index.html). Even with code splitting and lazy loading of chunks, the application developer can ensure that user gets a pleasant experience like displaying a progress bar or loading spinner instead ( using React Suspense ). This is much better than the frustrating experience of waiting for a page reloading everytime. Webpack ensures the chunkhash changes only for chunks which have changes in source code from previous build. This helps to take advantage of browser caching so that the request for chunks don't need to go to server everytime. Hope this was helpful !
I'm wondering how does whatsappweb deliver updates?
Do you ever notice a left green card appearing sometimes and asking you to click in a link to refresh page and run the new whatsappweb fresh code updated.
I'm almost sure they use webpack, service workers etc.
Chances are that you already had cache problems using webpack where even refreshing page it remains cached.
So how does whatsappweb solved this issue with a single refresh link?
They use a service worker, if the service worker gets updated, they trigger something in the react app, is easy to do it.
serviceWorker.register({ onUpdate: () => {console.log('new service worker')}});
just dispatch something instead of the console.log
Webpack is a building tool and isn't involved anywhere on a live site. While it offers Hot Module Reload for the development server you will not get it on the production version.
Unlike traditional desktop applications, delivering updates for websites is as straightforward as updating the files on your server (and invalidating any browser caches). You don't need to notify the user to download something, a simple refresh will get the new pages.
If you really want instantaneous updates (without waiting for the user to refresh the page) you can create some sort of WebSocket communication which when a message is received triggers a browser refresh. Nothing special and no deployment mechanisms involved.
Hello guys i am new to React Js i often hear and see posts regarding react is single page app but never understood what is SPA and many say that it doesn't reload the pages but i didn't understood why so could you guys please explain me with simple examples.
A Single Page Application is a web application or website that interacts with the web browser by dynamically rewriting the current web page with new data from the web server, instead of the default method of the browser loading entire new pages.
This means that the URL of your website will not change completely (page will not reload), instead it will keep getting content and rewriting the DOM with it instead of loading a new page.
The goal is faster transitions that make the website feel more like a native app
Example: Netflix
This is the dashboard, and when we click on any movie, it changes to /watch and the content is rewritten.
In Technical Terms:
When building your react-app, you can see that there is only one
App.js from where your entire web-app is loaded in fragments and
components. This behaviour of rendering components and pages on a single page and changing the DOM( is a single page behaviour and hence the name), instead of loading a new page with new content, this makes it feel like a single application.
As mentioned in Glossary of React Terms:
A single-page application is an application that loads a single HTML page and all the necessary assets (such as JavaScript and CSS) required for the application to run. Any interactions with the page or subsequent pages do not require a round trip to the server which means the page is not reloaded.
And about "Why is React Js called as Single Page Application":
Though you may build a single-page application in React, it is not a requirement. React can also be used for enhancing small parts of existing websites with additional interactivity. Code written in React can coexist peacefully with markup rendered on the server by something like PHP, or with other client-side libraries. In fact, this is exactly how React is being used at Facebook.
A single page application has one single page e.g. www.google.ch. It is exactly one HTML file (with all its required dependencies) loaded into the browser. You'd navigate between paragraphs only using hash-router, but never ever visit another page like www.google.ch/maps (that would then be www.google.ch/#maps, which references / -> index.html) (tho google may not be the best example, it is more about URIs).
ReactJS is an open source JS library for building UI and used for SPA, and it manages the views of web apps. Reactjs can help you to modify your data without reloading of a page. It is a popular library in the market trend because of its scalability & fast performance.
Single Page applications are different from multiple page apps that we see everywhere because the SPA doesn't move into new pages; instead, it will load the pages inline within the same page.
In traditional websites, when we go from one page to another, the whole site is loaded. e.g - if you go from "www.example.com/hi" to "www.example.com/hello" the whole website is reloaded. No matter how much portion of the website is really changed. Let's say, the website has "Sidebar, logo, menu" on both of its pages, then the full reload doesn't make any sense. This takes too much time and decreases the performance.
Single Page Applications, as the name suggests, have only one single page that is loaded the first time you open the website. After this, no matter where you click, it is not gonna refresh the website fully.
browser reload button
The loading icon of the browser doesn't load when we move from one page to another on SPA site, as it does on the traditional websites.
Cons- SPA sites are great for UI UX but they are not the best when it comes to Search Engine Optimisation, it creates problems with rankings.
The actual loading time of a web page and the user impression of that loading time can be quite different. For example, here are three different experiences a user can have while a page loads:
Waiting for a blank page to completely render at once
Parts of the page immediately render (e.g. top navigation) but components load
individually
The entire page is made of components that load individually
These different UI experiences become more common as JavaScript frameworks become more common, such as React or Angular.
The user's UI experience can also change if individual components use loading markers to indicate something is happening, such as Loading... or a spinning wheel.
What are some guidelines for improving the user impression of a fast loading page? If there are not any, how do you approach this problem?
There is always going to be an initial hit whilst the javascript gets parsed and executed. However, if you are after very fast initial loads you could try a few techniques such as:
Delivering a "critical" payload first which will quickly load the "essentials" of your webpage to make it feel much more responsive. Webpack has a code splitting feature that you could use for this effect.
Making use of Server Side Rendering (i.e. universal style applications) which will execute the javascript server side and embed the output in the HTML payload. This probably renders the best results for what you are after as you don't getting the "flashing" parts as much you would otherwise. It's a pretty cool technique but is probably presents more technical challenges so you will have to decide on your own tradeoffs.
If you are after an example of SSR you could look at a boilerplate I recently put together for React: https://github.com/ctrlplusb/react-universally
In that boilerplate I actually also make use of Webpack's code splitting feature based on the Routes defined within the application. Checkout webpack's docs on this: https://webpack.github.io/docs/code-splitting.html
If webpack is completely new to you I highly recommend the survive js series: https://survivejs.com/
Looking at this isomorphic react page: http://jlongster.com/Presenting-The-Most-Over-Engineered-Blog-Ever
I see that there is a Javascript variable at the bottom of the static content that represents the static content.
So the content is replicated when downloading.
Is this mandatory for the way react works? Any more efficient methods?
You need to have the data included so that you can mount the application on the client. The initial client side render must produce the same virtual dom as the server gave.
You could fetch it async, and wait until it downloads to mount the app, but there will be a significant delay between when the user reaches the page, and when JavaScript is actually applied. It'll also double the load on the database for initial requests.
Overall, server rendering will improve the time it takes for the user to see content, improve SEO, enable page caching with a CDN, and other benefits that outweigh the costs by far.
It's less important for sites behind a login, and you can often save significant development time by omitting it.