Search

CN-121983351-A - Web first screen streaming rendering method of medical bedside terminal

CN121983351ACN 121983351 ACN121983351 ACN 121983351ACN-121983351-A

Abstract

The invention belongs to the field of intelligent medical treatment, in particular to a Web first screen streaming rendering method of a medical bedside terminal, which comprises the following steps of S1, configuring front-end progressive rendering; the method comprises the steps of S2, resource priority and sub-packaging strategy, S3, data side optimization, S4, injection of a skeleton screen to achieve progressive rendering, construction of a minimum entry to render a skeleton and rapid take over of key interaction, S5, delay of hydration/hydration on demand, and S6, weak network self-adaption. The invention adopts the skeleton and progressive hydration to filter and display the page platform, and gradually has all interactive capability, thereby smoothing user experience, reducing first packet flow, obviously reducing perception delay of users and greatly improving response speed of medical equipment.

Inventors

  • LIN JIANQI
  • HUANG JIE

Assignees

  • 厦门狄耐克物联智慧科技有限公司

Dates

Publication Date
20260505
Application Date
20251220

Claims (9)

  1. 1. A medical care bedside terminal Web first screen streaming rendering method is characterized by comprising the following steps: s1, configuring front-end progressive rendering, wherein the specific steps are as follows: s101, first rendering only mounts a minimum Vue runtime code and a skeleton pattern; s102, using a skeleton screen component to occupy a place, rapidly drawing a primary visual element, then requesting key data in parallel and replacing a skeleton by v-if/v-show; S103, adopting 'delay hydration' or 'hydration on demand' for the interaction control, wherein key buttons and forms can be immediately realized by a small event processor, and non-key complex components are asynchronous hydrate in the background; S2, a resource priority and sub-packaging strategy is that code segmentation and static resource priority are used, pictures and icons occupy space and lazy load high resolution, and then Gzip compression is started to accelerate concurrent resource acquisition; and S3, optimizing the data side, wherein the data side is specifically as follows: s301, the back end only returns the minimum field required by the first screen in the first batch of responses, wherein the minimum field required by the first screen is the important information of the name, the bed number, the diagnosis, the allergy and the operation of the patient; S302, secondary data is acquired through background flow or delay fetch; s4, injecting a skeleton screen to achieve progressive rendering, constructing a minimum inlet to render the skeleton and rapidly taking over key interaction; s5, delaying hydration/hydration on demand; S6, weak network self-adaption.
  2. 2. The method for Web head-of-a-screen streaming rendering of a bedside terminal of medical care according to claim 1, wherein in S101, the skeleton style is controlled to be 150-250KB.
  3. 3. The method for Web first-screen streaming rendering of a medical bedside terminal according to claim 1, wherein in S103, the non-critical complex component is a chart or a rich text.
  4. 4. The method for Web first screen streaming rendering of the medical bedside terminal according to claim 1, wherein in the step S2, fonts of pictures and icons are font-display: swap.
  5. 5. The method for Web first screen streaming rendering of a medical bedside terminal according to claim 1, wherein in S5, the specific steps of delaying hydration/on-demand hydration are as follows: S501, in an initial loading stage, when only a mounted core runs during page loading, the volume is about 150-250KB, the HTML output comprises a static skeleton screen structure and key buttons, and all complex components are marked as data-hydration= "lazy"; S502, immediately hydrating a key area, namely immediately hydrating a key interaction component after skeleton rendering is completed, and loading the component as required by using defineAsyncComponent () and v-if; s503, background asynchronous hydration, namely triggering asynchronous loading of non-key components, such as a statistical chart, a monitoring curve and a message log, after the browser is idle or user interaction is completed, activating the components loaded in the background through an await report () and registering the components in a Vue instance; s504, performing real hydration when the component enters the viewport for the first time, and if the user does not scroll to the corresponding region, keeping the static occupying state of the component and not triggering the running logic.
  6. 6. The method for Web first screen streaming rendering of a bedside care terminal according to claim 5, wherein in 501, the complex components are charts, rich text and dynamic forms.
  7. 7. The method for Web first-screen streaming rendering of a bedside-care terminal according to claim 5, wherein in S504, the detection of the first entry of the component into the viewport is accomplished by IntersectionObserver listening, and in addition, for limited devices when hydration is required, a maximum number of concurrent hydration can be set to balance performance.
  8. 8. The Web first screen streaming rendering method of the medical bedside terminal according to claim 1, wherein in S6, the specific steps of the weak network adaptation are as follows: s601, starting detection, namely detecting the current network state when a page is initialized, entering an offline mode if an | navigator. Online is detected, and starting a lightweight mode if the network is poor; S602, a lightweight loading strategy, which specifically comprises the following steps: S6021, forbidding loading of large-volume resources; s6022, loading a skeleton page and key data JSON; s6023, delaying the registration of the third party plug-in; S6024, only loading basic theme by the CSS and the font resource; S603, a hierarchical recovery strategy, namely, once the network is recovered, automatically switching to a full-scale mode, asynchronously loading an unloaded module to replace a lightweight component, and recovering the connection of a real-time data stream and a WebSocket; and S604, a power saving strategy, namely if conn.saveddata=true, disabling automatic updating, animation and video playing, preferentially requesting low-resolution images and delaying background data polling.
  9. 9. The method for Web head-of-line streaming rendering of a bedside health care terminal according to claim 8, wherein in S603, whether the network is restored is determined by monitoring an online event.

Description

Web first screen streaming rendering method of medical bedside terminal Technical Field The invention relates to the technical field of intelligent medical treatment, in particular to a Web first screen streaming rendering method of a medical bedside terminal. Background Along with the popularization of intelligent medical treatment, a medical care bedside terminal becomes an important component of hospital informatization, and key modules such as patient information, medical advice, call buttons, real-time states and the like are usually required to be displayed. The traditional SPA scheme packs a large number of JS/CSS into a single body or delays the improper loading strategy, so that the first screen visualization (FCP/LCP) and the interactive (TTI) are prolonged, the clinical use efficiency and the user experience are affected, and especially in a local area network or weak network environment of a hospital, the reduction of the first package and the early rendering of a key UI are vital to the responsiveness, so that a Web first screen streaming rendering method of a medical bedside terminal is provided. Disclosure of Invention The invention provides a Web first screen streaming rendering method of a medical bedside terminal, which solves the problems existing in the prior art. In order to achieve the above purpose, the present invention adopts the following technical scheme: a medical care bedside terminal Web first screen streaming rendering method comprises the following steps: s1, configuring front-end progressive rendering, wherein the specific steps are as follows: s101, first rendering only mounts a minimum Vue runtime code and a skeleton pattern; s102, using a skeleton screen component to occupy a place, rapidly drawing a primary visual element, then requesting key data in parallel and replacing a skeleton by v-if/v-show; S103, adopting 'delay hydration' or 'hydration on demand' for the interaction control, wherein key buttons and forms can be immediately realized by a small event processor, and non-key complex components are asynchronous hydrate in the background; S2, a resource priority and sub-packaging strategy is that code segmentation and static resource priority are used, pictures and icons occupy space and lazy load high resolution, and then Gzip compression is started to accelerate concurrent resource acquisition; and S3, optimizing the data side, wherein the data side is specifically as follows: s301, the back end only returns the minimum field required by the first screen in the first batch of responses, wherein the minimum field required by the first screen is the important information of the name, the bed number, the diagnosis, the allergy and the operation of the patient; S302, secondary data is acquired through background flow or delay fetch; s4, injecting a skeleton screen to achieve progressive rendering, constructing a minimum inlet to render the skeleton and rapidly taking over key interaction; s5, delaying hydration/hydration on demand; S6, weak network self-adaption. Preferably, in S101, the skeleton style is controlled to be 150-250KB. Preferably, in the step S103, the non-critical complex component is a chart or a rich text. Preferably, in the step S2, fonts of the pictures and the icons adopt font-display: swap. Preferably, in S5, the specific steps of delayed hydration/on-demand hydration are as follows: S501, in an initial loading stage, when only a mounted core runs during page loading, the volume is about 150-250KB, the HTML output comprises a static skeleton screen structure and key buttons, and all complex components are marked as data-hydration= "lazy"; S502, immediately hydrating a key area, namely immediately hydrating a key interaction component after skeleton rendering is completed, and loading the component as required by using defineAsyncComponent () and v-if; s503, background asynchronous hydration, namely triggering asynchronous loading of non-key components, such as a statistical chart, a monitoring curve and a message log, after the browser is idle or user interaction is completed, activating the components loaded in the background through an await report () and registering the components in a Vue instance; s504, performing real hydration when the component enters the viewport for the first time, and if the user does not scroll to the corresponding region, keeping the static occupying state of the component and not triggering the running logic. Preferably, in 501, the complex components are charts, rich text, and dynamic forms. Preferably, in S504, the first detection of the component entering the viewport is performed by IntersectionObserver listening, and in addition, for limited devices when hydration is needed, the maximum number of concurrent hydration may be set to balance performance. Preferably, in the step S6, the specific steps of the weak network adaptation are as follows: s601, starting detection, namely detecting the current network state w