In Next.js 13, there is a new feature called "hybrid mode" which allows you to choose how your pages are rendered on the client and server. How this feature use to optimize the performance of a large web application with many dynamic pages that require server-side rendering?
Additionally, how would you handle the case where a page contains both static and dynamic content, and you want to optimize the rendering of both?
how would you handle the case where a page contains both static and dynamic content, and you want to optimize the rendering of both?
Related
I'm working on a project, which has two applications, one is an admin portal where users can customize and create their profile and other one is an application which will preview the profile user creates.
All good with the admin portal, which is developed with CRA - React App. Earlier I was planning creating profile app also with React. Anyhow considering SEO and performance I'm thinking about pre-rendering the profile whenever user changes data.
This will improve the performance by considerable margin and SEO as well. SSR is another good solution, however when there are thousands/millinos of users view single profile, there will be a huge demand for server performance. So that I'm planning to work on a POC, which will create static profile with partial cliend side js functionalities for each user and store it somewhere and serve it through CDN.
I want to know two things here -
To implement this, I'm having lack of knowledge in terms of available solutions. Solutions for storage, cdn.
How can we render static pages during the data changes.
To implement this, I'm having lack of knowledge in terms of available
solutions. Solutions for storage, cdn.
Check Cloudflare CDN. But there are many other proveriders.
How can we render static pages during the data changes.
If you are using pre-rendering, You can rebuild the page assets after a profile page is updated and redeploy them.
If you are using SSR then the server load will be high but no need to redeploy (as the page is rendered at runtime from the origin server always).
I would recommend you use Next.JS support for server rendering and pre-rending instead of implementing them on your own.
Currently, my project has two parts, one is before login, and one is after login.
What I want to achieve is, before login needs to be fast and SEO friendly, should I choose pre-render or SSR?
And after login, we can choose CSR (so the client is able to wait for the page to load).
Alternatively, can I do two CSRs, one for before login (fast load), and once client logged in, by JWT token, redirect to the after login CSR page?
Thanks
For pages that need to be crawled, most probably CSR is not an option. The question then becomes whether you choose to pre-render or SSR. The answer to that is that it depends.
Is the SEO content static, or does it depends on other some backend API response at a given time?
If it's static, pre-render should be enough for you. But if it depends on other APIs, the content could change during runtime, and you would have to do true SSR to accommodate that. SSR is more resource intensive on the server though.
As for the after login part, because it probably shouldn't be crawled by bots anyway, it is okay to do CSR for all the logged in pages. CSR alone doesn't mean you will have a significantly faster initial load though, there is a lot of factor to consider such as the HTML document size, network trip latency, the response time of the other services your own service is depending on, etc. BUT, along with using a service worker and using the app-shell model, CSR should almost always be faster compared to SSR. I would recommend looking into that to improve CSR speed. Link
It depends.
if SEO is irrelevant — e.g. an app that lives behind a login screen — then CSR is fine and you just need something like ReactJS
If you need a good SEO:
a) If you can predict the content to generate it in build time (eg: a blog), then you need SSG (static content created on build time) and should choose something like Gatsby or NextJS
b) If you can’t predict the content/possible request (eg: a search page), the server will need to generate the pages on demand, so you need dynamic SSR (content created on user access time) and should choose something like NextJS.
Note: NextJS allows you to selectively mix in the same project the 3 main rendering forms. For that reason is the best option if you need SEO.
If building a react app produces only static files how can dynamic websites be created with react?
Or can react build dynamic content too?
I have only made statics websites with react.
The short answer is yes - React can provide dynamic content.. You can also configure React to be a "dynamic" site (aka server side rendered) by using something like Next.js
Rather useful article..
To elaborate...
The relationship between a dynamic site and dynamic content is not mutually exclusive. A static site can most definitely provide dynamic content..
When you boil it down, a NON-static, or dynamic, website essentially refers to a website (or certain pages within a website) that are rendered server side. A static site refers to a website (or certain pages within a website) that are pre-built and then served to the client..
In the case of 'dynamic' websites, dynamic data is gathered server side and injected into html via some sort of a templating engine.. (Razor on ASP, Handlebars on Node, Jinja on Flask, to list some examples) ... As for 'static' sites, dynamic data is usually retrieved from a backend API that resides in a separate location than the web server that served the 'static' content - the requests, etc are all performed FROM THE CLIENT SIDE..
Basically, take the terms "dynamic site" and "static site" with a grain of salt.. Dynamic content is not mutually exclusive to either paradigm, and can exist using either paradigm.. You can have a dynamic site that doesn't have dynamic data..
Dynamic sites inject dynamic data into html server side, then send it to the client for viewing. Static sites gather dynamic data from a server somewhere (could be an API you control, or some 3rd party API), and then inject that data into the markup - difference is this is ALL done client side. If you wanted to retrieve data from a third party API using a dynamic/server side rendered site, the client would request a page from your web server, then your web server would query the 3rd party API, and inject that into HTML, then send the HTML back to you..(at a high level).. With that being said - you can still call 3rd party APIs client side, manipulate data, and manipulate the DOM client side, when using server side rendering..
Static sites basically send the entire website to the client (at a high level) upon the initial request - even if it contains multiple "pages".
React can be inter-mixed with dynamic server-side code such as PHP, ASP.Net, etc. In the case of ASP.Net, you can just use the React templates for ASP.Net, rather than using pure React-only templates such as CRA, or NEXT, or you can install React manually into your ASP.Net project.
If you want to build a React App that strictly produces static files for some reason, and still want some dynamic behaviour (e.g. loading from database), then you might want to look at JAMStack. The main idea is for dynamic operations, you either:
Get the dynamic data from an API on the run-time of your static pages
Get the dynamic data from an API on build/compile time using Static Site Generators (SSG)
What is the best approach/ strategy to implementing Accelerated Mobile Pages (https://www.ampproject.org/) within AEM 6.1 for a responsive web site that already renders for both desktop and mobile?
An initial concern is that you would be creating duplicate pages of content. So is it possible that AMP and normal html can share the same content?
Would you always redirect to AMP if mobile, and what is the best way to do that?
How would an author handle both AMP and standard pages?
More information is required to completely answer your question -
What is your approach towards responsive design (if you are supporting desktop)? Are mobile site and desktop site different?
What version of AEM are you using?
How would an author handle both AMP and standard pages?
Authoring is something which is not AMP specific, AMP is a feature/behavior that you would enforce on Publish instance and not Author. But this depends on your approach towards responsive behavior - single site handing both mobile and desktop or separate?
a) If there are separate sites then you would actually cater to AMP behavior on author as well by having different components/resource types and page templates for it (This is how prior to AEM 5.6 mobile sites were handled). I can provide more details if you are following this approach
b) If there is single site then you should configure this at publish only.
is it possible that AMP and normal html can share the same content?
In short Yes, depends on how you design your components and/or what version of AEM are you using. In AEM 6.2, Adobe has introduced content fragments that allows channel agnostic content management i.e. more like assets.
If you are not using AEM 6.2, even then you can allow for reusable content by designing for it. You could create a global space with content pieces and then use reference component to associate/use that content on different pages (the only challenge with this is to manage full text search if you have that on your site).
Would you always redirect to AMP if mobile, and what is the best way
to do that?
What ever approach you take a) or b) (as described in first answer), the essence for managing the redirects/rewrites is to exploit user-agent information in request. Apache/httpd allows to handle user-agent information and do a redirect of rewrite.
For approach a) you will redirect to your mobile site after identifying that user-agent is mobile user-agent and for approach b) you could rewrite the url (not redirect) add a selector that allows for you AMP specific resource scripts to render the content. Selector based solution is one possible way of implementing the single site for both web and AMP
UPDATE:
Assuming that you need to cache both AMP version and normal HTML markup, the solution is to use a special selector for rendering AMP version of markup. You could setup a component hierarchy -
Lets say your base page structure is abstracted out in a custom component called - AbstractPageComponent (this in most cases is replica of foundation/components/page customized to project need) and all your page components extend this component. What you could do is create another such component lets say AMPAbstractPageComponent, setup this page structure similar to standard Abstract component i.e. let it have its own copy of scripts head,body,content, header,footer etc. But make sure you name them differently from the convention in AbstractPageComponent, u could do that by pre-pending amp to them like amp-head.html, aem-body.html,amp-content.html. Then there will be AMPAbstractPageComponent.html the component rendering script that structures the page by including relevant AMP scripts and/or AbstractPageComponent scripts.
Each of these scripts should have the AMP specific logic and where-ever you need to refer to HTML logic include/defer to the AbstractPageComponent's script.
Now define the selector script to ensure AMP specific rendition, let say your selector is amp then in AbstractPageComponent create a amp.html or amp.jsp and in this script include AMPAbstractPageComponent.html
NOTE: The ideal structure to implement will be foundation Page -> AbstractPageComponent -> AMPAbstractPageComponent -> Other page templates
I have specified AMPAbstractPageComponent to be parent of AbstractPageComponent assuming that your site already exists and there is content pages referring to existing structure. If your site structure permits you to introduce AMPAbstractPageComponent between AbstractPageComponent -> Other page templates then you should do that and let AMPAbstractPageComponent handle that amp selector.
What i have defined above is the first level of change, next you need to consider the components inclusion that have AMP specific handling. For components included in templates you need pass on the selector amp if its coming in the URL otherwise included component will render their default script (component included in the templates not drag and dropped components).Dragged and dropped components will automatically try to render amp script if available and in case its not then default to its own script.
Please note, this is approach based on the selector resolution, for actual implementation to do AMP specific work you may have to do other stuff as well, another thing i have not included is the managing component rendering i.e if you normal html includes a parsys and that script in not included in your AMP implementation your components will not render. So you will either have to duplicate those inclusions in AMP specific scripts or you will have to include the AbstractComponent's scripts to include such components
Do a small PoC, I gave the approach solely based on high level understanding of what AMP does by reading the link you have specified.
I'm actually thinking about implementing the same and here is the thought path laid out so far (untested):
add new page extension handler at foundation/components/primary/cq/page (overlay it under /apps) named Page.amp.jsp with <%#include file="proxy.jsp" %> content
add page renderer into your application logic at the same place where are you rendering html pages
The rest should be done by ootb sling URL resolution handler
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.