A front-end lightweight multi-system penetration method and system

Abstract

The application discloses a front-end lightweight multi-system through method and system, and relates to the technical field of front-end optimization, which comprises the following steps: a front end acquires user behavior data, device performance and network conditions, combines unified standardized format data, dynamically schedules front-end resources and adjusts the priority of front-end resource loading; a multi-level front-end resource storage hierarchy is defined, front-end resources are stored in corresponding multi-levels, and front-end resource cache management is performed; on the basis of front-end resource cache management, user behavior data is compressed, the compression ratio is adjusted according to user behavior data and network conditions, and the front-end resources required by the user are dynamically selected and loaded from the front-end resource cache management. The application dynamically schedules the loading priority of front-end resources, improves the efficiency of page visible content reaching, and reduces the invalid loading proportion.

Description

Technical Field

[0001] This invention relates to the field of front-end optimization technology, and in particular to a method and system for lightweight multi-system integration of the front end. Background Technology

[0002] With the continuous development of front-end engineering architecture, cross-platform data interaction technology, and browser-side scheduling capabilities, front-end connectivity technologies for collaborative access to multiple business systems are gradually evolving from a single-page display model to multi-source heterogeneous data access, standardized structure processing, front-end resource scheduling, layered cache management, and dynamic rendering control. In enterprise applications, government service platforms, industrial visualization platforms, and integrated business portals, data generated by different systems is typically presented in heterogeneous formats such as CSV, XML, JSON, and SQL query results. In addition to handling interface display tasks, the front-end also needs to process multi-source data parsing, format unification, status awareness, and resource organization. Meanwhile, with the continuous enhancement of browser interface capabilities, research on user behavior awareness, terminal performance identification, network status analysis, and resource scheduling control is deepening.

[0003] While existing technologies can load front-end resources and display pages, in scenarios involving multiple interconnected systems, it is often difficult to form a unified resource scheduling mechanism based on real-time user behavior, terminal computing power status, and network transmission conditions. This can easily lead to problems such as unbalanced resource loading order and delayed presentation of key content. Summary of the Invention

[0004] In view of the aforementioned existing problems, the present invention is proposed.

[0005] Therefore, this invention provides a lightweight multi-system integration method for the front end to solve the problems of unbalanced resource loading order and delayed presentation of key content.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: In a first aspect, the present invention provides a front-end lightweight multi-system integration method, which includes, It identifies multiple data formats and unifies them to generate standardized data in a unified format. The front end acquires user behavior data, device performance, and network conditions, and combines this with data in a unified and standardized format to dynamically schedule front end resources and adjust the loading priority of front end resources. After adjusting the priority of front-end resource loading, define a multi-level front-end resource storage hierarchy, store the front-end resources in the corresponding multi-level hierarchy, and perform front-end resource caching management. Based on front-end resource cache management, user behavior data is compressed, the compression ratio is adjusted according to user behavior data and network conditions, and the front-end resources required by the user are dynamically selected and loaded from the front-end resource cache management. After the resources are loaded, the front-end calls the back-end interface. The back-end receives the user behavior data sent by the front-end, and the front-end renders the page based on the user behavior data, rendering and displaying the page content required by the user.

[0007] As a preferred embodiment of the front-end lightweight multi-system integration method described in this invention, the specific steps for identifying multiple data formats and unifying them to generate unified standardized format data are as follows: Identify CSV, XML, JSON, and SQL data from multiple data formats; Convert each row of CSV data to JSON data, map each element of XML data to JSON data, and convert each record of SQL data to JSON data. Merge multiple sets of data converted to JSON format into a unified, standardized format.

[0008] As a preferred embodiment of the front-end lightweight multi-system integration method described in this invention, the front-end acquires user behavior data, device performance, and network status, and combines this with data in a unified standardized format to dynamically schedule front-end resources and adjust the loading priority of front-end resources. The specific steps are as follows: Real-time monitoring of user clicks, scrolling, dwell time, update time, error rate, and access frequency on the front-end page serves as user behavior data; Obtain the number of CPU cores and memory usage times from the front end via the browser's API to assess device performance; Obtain the network bandwidth and latency of the front end as a measure of network status; Based on unified standardized data format and user behavior data, the priority of front-end resource loading is dynamically adjusted; When a user visits the page for the first time, front-end resources are loaded and displayed first. When the user scrolls through new content, front-end resources are loaded and displayed next; Based on user behavior data, device performance, and network conditions, formulate front-end resource loading strategies and collect front-end feedback data.

[0009] As a preferred embodiment of the lightweight multi-system integration method for the front end described in this invention, the steps of formulating a front end resource loading strategy by combining user behavior data, device performance, and network conditions, and collecting front end feedback data, are as follows: By comparing historical user behavior data with current user behavior data, a predictive logic algorithm is used to predict front-end resources and load them in advance. Based on the number of CPU cores, determine the performance of the front-end device; for devices with poor performance, adjust the number of front-end resources loaded. Adjust the loading order of front-end resources and the number of resources loaded concurrently on the front-end based on the front-end's network bandwidth and latency; Based on user behavior data, device performance, and network conditions, dynamically adjust the user's selection of front-end resources and generate a front-end resource loading strategy. The browser's API is used to record the time from request to completion of loading for each front-end resource, and to evaluate the front-end resource loading performance. Record user behavior data, device performance, front-end resource loading, and the time from front-end resource request to completion loading, generate performance feedback data, and optimize front-end resource loading strategies.

[0010] As a preferred embodiment of the front-end lightweight multi-system integration method described in this invention, after adjusting the front-end resource loading priority, a multi-level front-end resource storage hierarchy is defined, front-end resources are stored in the corresponding multi-level hierarchy, and front-end resource caching management is performed. The specific steps are as follows: Define the multi-level front-end resource storage hierarchy as RAM and hard disk; Based on the access frequency, update time and error rate in user behavior data, and by viewing data attributes from a unified standardized data format, the data size is obtained, and a cache level score for front-end resources is generated. Set access thresholds based on cache level scoring; If the cache level score exceeds the access threshold, the front-end resources will be stored in RAM. If the cache level score does not reach the access threshold, the front-end resources will be stored on the hard drive.

[0011] As a preferred embodiment of the front-end lightweight multi-system integration method described in this invention, the steps include: compressing user behavior data based on front-end resource caching management, adjusting the compression ratio according to user behavior data and network conditions, and dynamically selecting and loading the front-end resources required by the user from the front-end resource caching management. User behavior data is compressed using the Brotli compression algorithm; Define compression ratios as high compression, medium compression, and low compression. User behavior data is defined as heavyweight, mediumweight, and lightweight. High compression is used when network bandwidth is slow, network latency is long, and user behavior data is heavyweight. When network bandwidth is normal and user behavior data is of medium magnitude, use medium compression. Low compression is used when network bandwidth is fast, network latency is normal, and user behavior data is lightweight. The compression ratio is dynamically adjusted based on the network bandwidth and latency at the front end, as well as the data size in the user behavior data. The compressed user behavior data is transmitted via the HTTP protocol; Adjust the loading order of front-end resources based on the access frequency of user behavior data and the front-end device resource status.

[0012] As a preferred embodiment of the lightweight multi-system integration method for the front end described in this invention, after resource loading is completed, the front end calls the back end interface, the back end receives user behavior data transmitted by the front end, and the front end renders the page based on the user behavior data, rendering and displaying the page content required by the user. The specific steps are as follows: The front-end uses AJAX to send an HTTP request to the back-end, receives the compressed user behavior data, and decompresses it. The front-end uses JavaScript to render and layout user behavior data; For front-end resources that exceed the access threshold, the front-end quickly loads and displays them from the memory cache; for front-end resources that do not reach the access threshold, the front-end gradually caches and displays them from the disk cache.

[0013] Secondly, this invention provides a front-end lightweight multi-system interconnection system, including, The recognition module is used to identify multiple data formats and unify them to generate standardized data. The adjustment module is used to obtain user behavior data, device performance and network status from the front end, and combine them with unified standardized data format to dynamically schedule front end resources and adjust the loading priority of front end resources, and display loading. The management module is used to define multi-level front-end resource storage layers after adjusting the priority of front-end resource loading, store front-end resources in the corresponding multi-level layers, and manage front-end resource caching. The loading module is used to compress user behavior data based on front-end resource cache management, adjust the compression ratio according to user behavior data and network conditions, and dynamically select and load the front-end resources required by the user from the front-end resource cache management. The rendering module is used to load resources, and then the frontend calls the backend interface. The backend receives the user behavior data sent by the frontend, and the frontend renders the page based on the user behavior data, rendering the page content required by the user and displaying it.

[0014] Thirdly, the present invention provides a computer device including a memory and a processor, wherein the memory stores a computer program, wherein: when the computer program is executed by the processor, it implements any step of the front-end lightweight multi-system integration method as described in the first aspect of the present invention.

[0015] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein: when the computer program is executed by a processor, it implements any step of the front-end lightweight multi-system integration method as described in the first aspect of the present invention.

[0016] The beneficial effects of this invention are as follows: By dynamically scheduling the loading priority of front-end resources by combining user behavior data, device performance, and network conditions, a front-end resource priority queue can be established around the content that the user is currently interested in. Based on the terminal processing power, network bandwidth, and network latency, key styles, scripts, images, and data resources are loaded in a hierarchical manner, preloaded predictively, and their order adjusted in real time. This makes the content on the first screen of the page, the content related to the current operation, and the content that may be accessed later form a more orderly resource entry mechanism in the rendering chain, thereby improving the efficiency of visible content reaching the page, reducing the proportion of invalid loading, enhancing the continuity of interaction, and providing a stable data foundation and scheduling foundation for subsequent cache management, compressed transmission, and dynamic rendering. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart of the front-end lightweight multi-system integration method in Example 1.

[0019] Figure 2 This is a module diagram of the front-end lightweight multi-system integration method in Example 1. Detailed Implementation

[0020] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0021] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0022] Secondly, the term "one embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that is mutually exclusive with other embodiments.

[0023] Reference Figure 1 and Figure 2 This is the first embodiment of the present invention, which provides a lightweight multi-system integration method for the front end, including the following steps: S1. Identify multiple data formats and unify them to generate standardized data in a unified format.

[0024] Furthermore, using pandas and xml.etree.ElementTree in Python, it can automatically recognize CSV, XML, JSON, and SQL format data; Specifically, pandas is used to read CSV files. By recognizing commas (or other delimiters) in the file, pandas automatically parses each row to determine the number and type of fields, thus identifying that it is CSV format data. Features include: comma delimiters, possible header rows (column names), and each row representing a record. The XML file is parsed using xml.etree.ElementTree, which scans the XML tag structure to identify start tags, end tags, attributes, and data content, thus determining that it is in XML format. Features include: hierarchical structure, tag names, and possible namespaces. Although JSON format is the target format, it is still parsed using pandas or directly using Python's json function to identify JSON key-value pairs, arrays, and nested structures. SQL query results are typically obtained through pandas' read_sql function or directly from a database connection. Identifying features include: table structure (column names), data type, and each record being a row. The identified CSV, XML, JSON, and SQL data are processed using JSON in Python. Convert each row of CSV data into JSON data using pandas in Python. In Python, xml.etree.ElementTree maps each element of XML data to JSON data. Convert each record of SQL-formatted data into JSON format using pandas in Python; Specifically, each row of the CSV is converted into a JSON object, where the column names become the keys and the data becomes the values. The JSON object is constructed using pandas' to_json method or manually, and the result is a JSON array where each element represents a row of data. Each element of the XML is mapped to a JSON object or array. The XML is parsed using xml.etree.ElementTree, and then the corresponding JSON structure is manually constructed, with the nesting determined according to the hierarchical relationship of the XML. If the data is already in JSON format, the structure is adjusted to conform to the expected standardized format, but the original JSON structure is mainly maintained. Each record in the SQL query result is converted into a JSON object, with column names as keys and record data as values, similar to CSV processing, directly from the SQL query result; During the conversion process, JSON Schema validation is performed to determine the standard for data format conversion; Specifically, for each converted JSON object, a predefined JSON Schema is used for validation. The Schema defines which keys are required, data type checks, nested structures, etc. The Python jsonschema library is used for validation to ensure that the converted data format meets the expected standards. Multiple data sets converted to JSON format are merged into a unified, standardized format and stored in a MongoDB database; It should be noted that by using automation tools in Python to unify various data formats into JSON format and store them in MongoDB, the data processing was automated and standardized, improving the quality of conversion, reducing errors, simplifying subsequent operations and integration, and enhancing compatibility and processing efficiency.

[0025] S2: The front end obtains user behavior data, device performance, and network status, and combines this with data in a unified standardized format to dynamically schedule front end resources and adjust the loading priority of front end resources.

[0026] Use JavaScript to monitor users' clicks, scrolling, dwell time, update time, error rate, and access frequency on the front-end page in real time, and generate user behavior data; Specifically, use JavaScript's addEventListener to listen for the click events of all clickable elements and record the elements clicked by the user and the time of the click. Using scroll listeners in JavaScript to capture user scrolling behavior, including the scroll position and scrolling speed, can help understand which parts of the page the user is focusing on. By setting JavaScript timers (such as setTimeout or requestAnimationFrame), the time users spend on different parts of the page can be calculated to help determine the user's interests. Use JavaScript event listeners (such as MutationObserver) to detect when page content is updated. For example, when page elements change, record the current time to calculate the time interval between content updates. Listen for and log JavaScript errors, using window.onerror to capture errors, and record the number and type of errors whenever an error occurs in order to calculate the error rate; Use timers (such as setInterval) or behavior-triggered events to count the number of times a user visits a specific resource or page. You can set a period (such as every minute or hour) to update the access frequency data; for example, increment the counter value every time a user visits a resource and periodically store or update it in the user behavior data. The device performance data can be generated by directly obtaining the number of CPU cores and memory usage times from the front end through the browser's API. Specifically, the number of CPU cores of the device is obtained through the browser's API navigator.hardwareConcurrency, which helps to assess the device's processing power; Memory status can be assessed using performance.memory (supported by some browsers) or indirect methods (such as monitoring JavaScript execution time); Use navigator.connection to obtain the front-end's network bandwidth and latency, and generate network status; Specifically, the front-end network bandwidth and latency are obtained through navigator.connection.effectiveType and navigator.connection.rtt. These network conditions are used to adjust the order and concurrency of front-end resource loading. For example, in a low-bandwidth, high-latency environment, it may be necessary to reduce concurrent requests. Based on unified standardized data formats and user behavior data, the priority of front-end resource loading (including image resources, CSS files, JavaScript files, HTML fragments, font files, JSON data, multimedia files, web components, static resources, and cached data) is dynamically adjusted. When a user visits the page for the first time, front-end resources are loaded and displayed first. When a user enters the page for the first time, key resources (such as CSS files, JavaScript files and font files) are loaded first to ensure that the content on the first screen is displayed quickly. When a user scrolls through new content, front-end resources are loaded and displayed next. When a user scrolls to new page content, the related resources of that content (such as images, dynamically loaded scripts, etc.) are loaded next to the key resources that are loaded first. Based on user behavior data, device performance, and network conditions, formulate front-end resource loading strategies and collect front-end feedback data; Specifically, by comparing historical user behavior data with current user behavior data, a predictive logic algorithm is used to predict front-end resources and load them in advance. Specifically, it involves extracting user behavior data from a MongoDB database or local storage, including browsing history, access frequency, and frequently viewed content types. Capture user data such as clicks, scrolling, and dwell time in real time; Use simple prediction logic (such as recently visited pages) to predict the resources that users may visit and output the predicted resources results; Specifically, suppose there is a news website where users exhibit the following behavior patterns: Historical behavior: Users check tech news every day from 3 PM to 5 PM; Frequently visited pages include the homepage, the list of technology news items, and the details page for specific technology news items; Historical behavior: The user just visited the homepage; The current time is 3:30 PM, which falls within the historical timeframe for users viewing tech news; Users visit the homepage, which is the beginning of their news browsing journey; Based on users' historical and current behavior, it is predicted that users are likely to click to view technology news after browsing the homepage; Based on past visits, users like to view the latest technology news, such as detailed reports on a popular technology product; Then preload, such as the JSON data of the tech news list (returned by the API), and thumbnails of the most important images on the tech news list page; When the user scrolls to near the end of the news list, more news images or content begin to load (lazy loading strategy). If a user clicks on the technology news category, preload the content of one or two popular news details pages under that category, such as the HTML structure, main image, and brief summary; Based on the number of CPU cores, determine the performance of the front-end device; for devices with poor performance, adjust the number of front-end resources loaded. Specifically, it involves obtaining the number of CPU cores to determine the device's processing capacity, assessing memory usage, and understanding whether the device can handle high-load front-end resources. For low-performance devices, reduce image quality (e.g., use WebP format or lower resolution images). Reduce the number of JavaScript files or use asynchronous loading; Limit the size of CSS files or use more concise stylesheets; Monitor the performance of front-end devices in real time and further adjust resource loading strategies, such as reducing the number of concurrent front-end resources or tasks when the performance of front-end devices degrades. Adjust the loading order of front-end resources and the number of resources loaded concurrently on the front-end based on the front-end's network bandwidth and latency; Specifically, use navigator.connection.effectiveType to evaluate the front-end network bandwidth (such as 4G, 3G, etc.). Get the front-end network latency using navigator.connection.rtt; In a high-bandwidth, low-latency environment, increase the number of concurrent front-end resource loads to quickly build pages; In low-bandwidth, high-latency environments, install front-end resources sequentially or in segments (such as lazy loading images). Prioritize loading front-end resources on critical rendering paths, such as main styles and scripts; Create a priority queue to dynamically adjust the user's selection of front-end resources based on user behavior data, device performance, and network conditions, and generate a front-end resource loading strategy; Specifically, priorities are set based on user behavior data (e.g., front-end resources related to the user's current operation have the highest priority). Considering the performance of the front-end devices, adjust the priority of front-end resources (e.g., on low-performance devices, cache more front-end resources to reduce network requests). Network conditions affect the order and concurrency of front-end resource loading; Update the priority queue in real time and adjust the loading order of front-end resources according to the new data; The browser's API is used to record the time from request to completion of loading for each front-end resource, and to evaluate the front-end resource loading performance. Specifically, the browser's PerformanceObserver API is used to track the loading time of front-end resources, recording the time from performance.now() to completion of loading for each front-end resource; Record metrics such as FCP, LCP, and FID, analyze the loading time of each front-end resource, and identify bottlenecks; A low FCP indicates that the page content loads quickly, and the user has a shorter time to see the content. A high FCP indicates a delay in loading front-end resources (such as CSS and basic HTML). In this case, check if there is a large CSS file blocking rendering, if too much JavaScript is blocking the initial content rendering, or if there are network request delays or bandwidth issues. A low LCP indicates that the main content loads quickly, and users can see the main content very quickly. High LCP indicates that the main content is loading too slowly. Check image or video resources (optimize image size, use WebP, etc.), server response time is long (optimize the backend or use CDN), check resource priority settings, if the settings are not set properly, it will cause the main content to load slowly. A low FID indicates good page interactivity and a fast response to user actions. A high FID means that JavaScript is still performing long tasks (such as complex calculations or a lot of DOM operations) while the user is inputting, and too much JavaScript is executed when the page loads, causing the main thread to be occupied. By analyzing performance logs, we can identify which JavaScript operations are causing the delay and optimize them. Record user behavior data, device performance, front-end resource loading, and the time from front-end resource request to completion loading, generate performance feedback data, and optimize front-end resource loading strategies; Specifically, it records each type of resource for user behavior data, saves front-end device performance metrics (CPU, memory), details of front-end resource loading (loading time, number of failures), generates performance feedback data, displays loading time distribution, failure rate, etc., and optimizes front-end resource loading strategies based on performance feedback data, such as adjusting priorities or modifying resource versions. It should be noted that by monitoring user behavior, device performance, and network conditions in real time, and combining this with unified data, front-end resources are dynamically scheduled, improving the response speed and user experience of front-end applications. Utilizing JavaScript and browser APIs, resources can be predicted and preloaded based on user behavior patterns, such as technology news on news websites, reducing user waiting time. Adjustments to resource loading strategies for different devices and network conditions ensure performance optimization, such as reducing image quality or adjusting script loading methods, ensuring smooth display in resource-constrained environments. The real-time feedback mechanism also allows for continuous optimization of loading strategies, improving overall performance and user satisfaction.

[0027] S3. After adjusting the priority of front-end resource loading, define a multi-level front-end resource storage hierarchy, store the front-end resources in the corresponding multi-level hierarchy, and perform front-end resource caching management.

[0028] Furthermore, the multi-level front-end resource storage hierarchy is defined as RAM and hard disk; Based on user behavior data, including access frequency, data size, update time, and error rate, a cache level score for front-end resources is generated. The expression is: ; in, The cache level is scored, which determines which storage level (such as memory, hard drive, etc.) should front-end resources be stored in. The higher the value, the more efficient the front-end resources should be stored in. Access frequency refers to the number of times or frequency a user accesses a resource. The use of frequency means that frequency has a non-linear impact on storage tier selection; frequently accessed resources will significantly improve their storage tier. This refers to the data size, expressed in bytes, and also represents the size of the front-end resource. Larger front-end resources may affect the likelihood of them being stored in an efficient storage tier, because larger resources occupy more storage space. It is a logarithmic function. To update time, the unit is usually an hour or other time unit. The +1 is added to prevent the update time from becoming zero. This increment ensures the logarithmic function remains meaningful during calculation, avoiding errors caused by taking the logarithm of zero or negative numbers. Error rate is reflected through user behavior data, such as the number of times a user encounters an error when accessing a front-end resource multiple times. This reflects the error rate of the front-end resource, but the error rate itself is a quality indicator of the front-end resource. Pi is approximately 3.14159. Based on cache level scoring, set access thresholds (e.g., accesses greater than or equal to 10 per hour). If the cache level score exceeds the access threshold, the front-end resources will be stored in RAM. RAM provides fast access and is suitable for frequently accessed resources to ensure a smooth user experience. If the cache level score does not reach the access threshold, the front-end resources will be stored on the hard disk. The hard disk provides a larger storage capacity, which is suitable for front-end resources that are not frequently accessed but still need to be read quickly. As user behavior changes, each C value is recalculated periodically or in real time, and its storage location is adjusted, possibly from hard drive to RAM, or from RAM to hard drive. When the original unified standardized format data is updated, ensure that all front-end resources at all cache levels are also updated synchronously to avoid the front-end resources in the cache becoming outdated; It should be noted that by dynamically generating the storage hierarchy of front-end resources based on access frequency, data size, update time, and error rate, the efficiency of cache management is improved. High-frequency resources are stored in RAM to ensure fast access, while low-frequency resources are stored on the hard drive to save efficient cache space. Real-time adjustment and synchronous updates ensure the timeliness and accuracy of cached data, optimize resource transmission efficiency, and improve user experience.

[0029] S4. Based on front-end resource cache management, compress user behavior data, adjust the compression ratio according to user behavior data and network conditions, and dynamically select and load the front-end resources required by the user from the front-end resource cache management.

[0030] Furthermore, user behavior data is compressed using the Brotli compression algorithm to reduce the amount of data. Generate compression quality based on network conditions and device performance; Define compression ratios as high compression, medium compression, and low compression. User behavior data is defined as heavyweight, mediumweight, and lightweight. High compression is used when network bandwidth is slow, network latency is long, and user behavior data is heavyweight. It should be noted that "heavyweight" user behavior data refers to a large total amount of data requested by the user, such as needing to load a large number of images (more than 20) or videos (more than 3). High compression is used to reduce the amount of data transmitted to adapt to environments with poor network conditions. When network bandwidth is normal and user behavior data is of medium magnitude (e.g., 0.5), medium compression should be used. It should be noted that the user behavior data volume is medium-level, which means that the amount of data requested by the user is at a medium level, which may be a few pictures (5-20 pictures) or a small number of videos (1-2 videos). Medium compression is used to balance the data volume and transmission speed. Low compression is used when network bandwidth is fast, network latency is normal, and user behavior data is lightweight. It should be noted that lightweight user behavior data means that the amount of data requested by the user is small, such as a few pieces of text or small icons (less than 5 images and no text and icon data such as videos). Using low compression ensures the quality of the data and preserves detailed information without excessive compression when network conditions are good. The compression ratio is dynamically adjusted based on the front-end network bandwidth and latency, as well as the data size in the user behavior data. The expression is: ; in, For compression ratio, For network bandwidth, Due to network latency, For data size, To improve compression quality and affect the compression ratio, arctan is the arctangent function, which plays an adjusting role in smoothing out the effects of compression. It should be noted that compression quality is determined based on network conditions (network bandwidth and latency at the front end), data size, and device performance, and is typically between 0 and 1, with 1 being the highest quality (minimum compression) and 0 being the lowest quality (maximum compression). Specifically, when network conditions are good (network bandwidth > 50 Mbps and network latency < 30 ms), high-quality compression should be used. =1), which maintains data quality and ensures fast transmission; When network conditions are poor (high network bandwidth <5Mbps and low network latency >150ms), use low-quality compression. =0), which reduces the amount of data and makes transmission faster; When the device has good performance (CPU > 4 cores and memory > 4GB), the device has strong processing power and can handle more complex compression algorithms, so high-quality compression (Q close to 1), such as Q=0.8, can be used to maintain the quality of the data; When the device performance is poor (CPU < 2 cores and memory < 2GB), the compression quality needs to be reduced to reduce the decompression calculation burden on the client, such as Q=0.3, to ensure the transmission speed; The compressed user behavior data is transmitted via the HTTP protocol; Adjust the loading order of front-end resources based on the access frequency of user behavior data and the device resource status of the front end; It should be noted that by utilizing the Brotli compression algorithm and dynamically adjusting the compression ratio based on network conditions and data size, the transmission efficiency of user behavior data is optimized. High, medium, and low compression are selected under different network conditions to ensure that the amount of data transmission is reduced when resources are limited, while data quality is preserved when conditions are favorable. Combined with user behavior and device performance, the dynamic loading strategy reduces resource waste and improves loading speed and user experience.

[0031] S5. After the resources are loaded, the front-end calls the back-end interface. The back-end receives the user behavior data sent by the front-end, and the front-end renders the page according to the user behavior data, rendering the page content required by the user and displaying it.

[0032] Furthermore, the front-end uses AJAX to send an HTTP request to the back-end, receive the compressed user behavior data, and decompress it. Specifically, the front end uses AJAX (possibly via fetch API or XMLHttpRequest) to send HTTP requests to the back end. These requests may contain user actions such as clicking a button or submitting a form. The backend returns Brotli compression, which is then decompressed. The compressed user behavior data includes updated user information, new content, etc. The front-end uses JavaScript to render and layout user behavior data; Specifically, the front end uses JavaScript to process user behavior data and decide how to display it, which involves DOM manipulation and using state management in frameworks such as React, Vue or Angular to update the UI; For front-end resources that exceed the access threshold, the front-end quickly loads and displays them from the memory cache; for front-end resources that do not reach the access threshold, the front-end gradually caches and displays them from the disk cache. Specifically, if front-end resources (such as frequently accessed images, user information, etc.) are evaluated as having a high access frequency (high C value), these front-end resources are already stored in memory. JavaScript will quickly retrieve and display these front-end resources from memory to reduce loading time. For front-end resources with a low access frequency (such as page content that is not frequently viewed or large files), they are stored in the disk cache. JavaScript will load these front-end resources gradually as needed, possibly through lazy loading, such as images or content blocks only starting to load when they enter the window. It should be noted that after the resources are loaded, the front end makes an AJAX request to the back end to receive and decompress the Brotli compressed data. It then uses JavaScript to process user behavior data, dynamically renders the page, and combines a caching strategy to load frequently accessed resources from memory and less frequently accessed resources from disk cache, thereby optimizing response speed and user experience and reducing network requests and loading time.

[0033] This embodiment also provides a lightweight multi-system interconnection system, including: The recognition module is used to identify multiple data formats and unify them to generate standardized data. The adjustment module is used to obtain user behavior data, device performance and network status from the front end, and combine them with unified standardized data format to dynamically schedule front end resources and adjust the loading priority of front end resources, and display loading. The management module is used to define multi-level front-end resource storage layers after adjusting the priority of front-end resource loading, store front-end resources in the corresponding multi-level layers, and manage front-end resource caching. The loading module is used to compress user behavior data based on front-end resource cache management, adjust the compression ratio according to user behavior data and network conditions, and dynamically select and load the front-end resources required by the user from the front-end resource cache management. The rendering module is used to load resources, and then the frontend calls the backend interface. The backend receives the user behavior data sent by the frontend, and the frontend renders the page based on the user behavior data, rendering the page content required by the user and displaying it.

[0034] This embodiment also provides a computer device applicable to the front-end lightweight multi-system integration method, including: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to realize the front-end lightweight multi-system integration method proposed in the above embodiment.

[0035] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0036] This embodiment also provides a storage medium storing a computer program that, when executed by a processor, implements the multi-system interconnection method for achieving front-end lightweighting as proposed in the above embodiments. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0037] In summary, this invention dynamically schedules the loading priority of front-end resources by combining user behavior data, device performance, and network conditions. It can establish a front-end resource priority queue around the content that the user is currently interested in, and implement hierarchical loading, predictive preloading, and real-time order adjustment of key styles, scripts, images, and data resources based on terminal processing power, network bandwidth, and network latency. This creates a more orderly resource entry mechanism in the rendering chain for the first screen content, the content related to the current operation, and the content that may be accessed later. This improves the efficiency of visible content reaching the page, reduces the proportion of invalid loading, enhances the continuity of interaction, and provides a stable data and scheduling foundation for subsequent cache management, compressed transmission, and dynamic rendering.

[0038] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A lightweight front-end multi-system integration method, characterized in that: include, It identifies multiple data formats and unifies them to generate standardized data in a unified format. The front end acquires user behavior data, device performance, and network conditions, and combines this with data in a unified and standardized format to dynamically schedule front end resources and adjust the loading priority of front end resources. After adjusting the priority of front-end resource loading, define a multi-level front-end resource storage hierarchy, store the front-end resources in the corresponding multi-level hierarchy, and perform front-end resource caching management. Based on front-end resource cache management, user behavior data is compressed, the compression ratio is adjusted according to user behavior data and network conditions, and the front-end resources required by the user are dynamically selected and loaded from the front-end resource cache management. After the resources are loaded, the front-end calls the back-end interface. The back-end receives the user behavior data sent by the front-end, and the front-end renders the page based on the user behavior data, rendering and displaying the page content required by the user.

2. The front-end lightweight multi-system integration method as described in claim 1, characterized in that: The specific steps for identifying multiple data formats and unifying them to generate standardized data are as follows: Identify CSV, XML, JSON, and SQL data from multiple data formats; Convert each row of CSV data to JSON data, map each element of XML data to JSON data, and convert each record of SQL data to JSON data. Merge multiple sets of data converted to JSON format into a unified, standardized format.

3. The front-end lightweight multi-system integration method as described in claim 2, characterized in that: The front-end acquires user behavior data, device performance, and network conditions, and combines this data in a unified standardized format to dynamically schedule front-end resources and adjust the loading priority of these resources. The specific steps are as follows: Real-time monitoring of user clicks, scrolling, dwell time, update time, error rate, and access frequency on the front-end page serves as user behavior data; Obtain the number of CPU cores and memory usage times from the front end via the browser's API to assess device performance; Obtain the network bandwidth and latency of the front end as a measure of network status; Based on unified standardized data format and user behavior data, the priority of front-end resource loading is dynamically adjusted; When a user visits the page for the first time, front-end resources are loaded and displayed first. When the user scrolls through new content, front-end resources are loaded and displayed next; Based on user behavior data, device performance, and network conditions, formulate front-end resource loading strategies and collect front-end feedback data.

4. The front-end lightweight multi-system integration method as described in claim 3, characterized in that: The process involves combining user behavior data, device performance, and network conditions to formulate a front-end resource loading strategy and collecting front-end feedback data. The specific steps are as follows: By comparing historical user behavior data with current user behavior data, a predictive logic algorithm is used to predict front-end resources and load them in advance. Based on the number of CPU cores, determine the performance of the front-end device; for devices with poor performance, adjust the number of front-end resources loaded. Adjust the loading order of front-end resources and the number of resources loaded concurrently on the front-end based on the front-end's network bandwidth and latency; Based on user behavior data, device performance, and network conditions, dynamically adjust the user's selection of front-end resources and generate a front-end resource loading strategy. The browser's API is used to record the time from request to completion of loading for each front-end resource, and to evaluate the front-end resource loading performance. Record user behavior data, device performance, front-end resource loading, and the time from front-end resource request to completion loading, and generate performance feedback data.

5. The front-end lightweight multi-system integration method as described in claim 4, characterized in that: After adjusting the priority of front-end resource loading, a multi-level front-end resource storage hierarchy is defined, and front-end resources are stored in the corresponding multi-level hierarchy. Front-end resource caching management is then implemented. The specific steps are as follows: Define the multi-level front-end resource storage hierarchy as RAM and hard disk; Based on the access frequency, update time and error rate in user behavior data, and by viewing data attributes from a unified standardized data format, the data size is obtained, and a cache level score for front-end resources is generated. Set access thresholds based on cache level scoring; If the cache level score exceeds the access threshold, the front-end resources will be stored in RAM. If the cache level score does not reach the access threshold, the front-end resources will be stored on the hard drive.

6. The front-end lightweight multi-system integration method as described in claim 5, characterized in that: Based on front-end resource caching management, user behavior data is compressed, the compression ratio is adjusted according to user behavior data and network conditions, and the front-end resources required by the user are dynamically selected and loaded from the front-end resource caching management. The specific steps are as follows: User behavior data is compressed using the Brotli compression algorithm; Define compression ratios as high compression, medium compression, and low compression. User behavior data is defined as heavyweight, mediumweight, and lightweight. High compression is used when network bandwidth is slow, network latency is long, and user behavior data is heavyweight. When network bandwidth is normal and user behavior data is of medium magnitude, use medium compression. Low compression is used when network bandwidth is fast, network latency is normal, and user behavior data is lightweight. The compression ratio is dynamically adjusted based on the network bandwidth and latency at the front end, as well as the data size in the user behavior data. The compressed user behavior data is transmitted via the HTTP protocol; Adjust the loading order of front-end resources based on the access frequency of user behavior data and the front-end device resource status.

7. The front-end lightweight multi-system integration method as described in claim 6, characterized in that: After resource loading is complete, the frontend calls the backend interface. The backend receives the user behavior data sent by the frontend, and the frontend renders the page based on the user behavior data, displaying the page content required by the user. The specific steps are as follows: The front-end uses AJAX to send an HTTP request to the back-end, receives the compressed user behavior data, and decompresses it. The front-end uses JavaScript to render and layout user behavior data; For front-end resources that exceed the access threshold, the front-end loads and displays them from the memory cache; for front-end resources that do not reach the access threshold, the front-end gradually caches and displays them from the disk cache.

8. A front-end lightweight multi-system interconnection system, based on the front-end lightweight multi-system interconnection method according to any one of claims 1 to 7, characterized in that: include, The recognition module is used to identify multiple data formats and unify them to generate standardized data. The adjustment module is used to obtain user behavior data, device performance and network status from the front end, and combine them with unified standardized data format to dynamically schedule front end resources and adjust the loading priority of front end resources, and display loading. The management module is used to define multi-level front-end resource storage layers after adjusting the priority of front-end resource loading, store front-end resources in the corresponding multi-level layers, and manage front-end resource caching. The loading module is used to compress user behavior data based on front-end resource cache management, adjust the compression ratio according to user behavior data and network conditions, and dynamically select and load the front-end resources required by the user from the front-end resource cache management. The rendering module is used to load resources, and then the frontend calls the backend interface. The backend receives the user behavior data sent by the frontend, and the frontend renders the page based on the user behavior data, rendering the page content required by the user and displaying it.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, it implements the steps of the front-end lightweight multi-system integration method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the steps of the front-end lightweight multi-system integration method according to any one of claims 1 to 7.

Images