Information technology

Simonov Mykhailo

SEO of Vision Lab Studio

(Ukraine, Kharkiv)

 https://www.doi.org/10.25313/2524-2695-2023-8-05-34

STRATEGIES FOR BALANCING VISUAL COMPLEXITY AND WEBSITE PERFORMANCE

Summary. The article systematizes open approaches to balancing the visual complexity of interfaces with website performance in terms of Core Web Vitals metrics. It explains how the complexity of the visual layer, including media, fonts, animations, and DOM depth, increases the cost of critical rendering and affects LCP (Largest Contentful Paint), INP (First Input Delay), and CLS (Cumulative Layout Shift). A framework model based on the “perceptual value ↔ computational cost” axis and a taxonomy of strategies for optimizing website performance are proposed. These strategies include adaptive media and font delivery, prioritizing uploads, JS fragmentation and postponement, controlling content visibility, RSC architectures, and other operational optimizations. Evaluation methods (CrUX/RUM, Lighthouse, Element Timing, LCP API, Long Animation Frames), as well as threshold considerations for implementing them in CI/CD, are described. This material is intended for developers and UX performance researchers.

Key words: visual complexity, web interface performance, Core Web Vitals, LCP, INP, CLS, critical rendering path, adaptive media delivery, font optimization, Fetch Priority, content-visibility, design budgets. 

Relevance of the study. The relevance of the research stems from the intersection of several trends in web development: an increasing focus on visual expressiveness, stricter performance metrics (Core Web Vitals), and a growing need for accessibility and sustainability. Modern websites are competing not only based on content and functionality, but also on the quality of their visual language.

At the same time, the proliferation of stylistic elements, such as fonts, animations, and complex graphic effects, directly increases the size of resources, the depth of the Document Object Model (DOM), and the rendering cost. On mobile devices, with their limited CPU/GPU capabilities and unstable network connections, this can lead to slower load times and reduced responsiveness. The balance between visual complexity and performance is an important economic factor that affects various aspects of a website or application. It impacts conversion rates, user retention, search engine optimization (SEO) visibility, the cost of traffic, energy consumption, and even legal and ethical considerations such as accessibility for users with cognitive or sensory disabilities.

The problem is further complicated by the fragmentation of technology stacks. The widespread use of JavaScript on the client side, third-party widgets, and analytics, as well as various delivery strategies such as CDN/edge, server-side rendering (SSR), and HTTP/2/3, along with different screen form factors and regional network variations, create a “moving target” for optimization. There is no consistent model in scientific or practical literature that simultaneously addresses visual complexity (both cognitive and structural-technical aspects) and connects it to metrics of real-world user experience.

Therefore, developing theoretically sound and reproducible balancing strategies has high scientific and practical significance: it provides organizations with manageable “expressiveness ↔ speed” tradeoffs, reduces the risk of UX degradation when scaling a product, and ensures sustainable compliance with quality and accessibility standards.

The purpose of the study. The aim of this study is to establish a replicable framework model and taxonomy of strategies for managing the “visual complexity ↔ performance” balance in projects, and to verify the impact of optimizations at the Core Web Vitals level through field and laboratory tests.

The results of the study. The concepts of “visual complexity” and “performance” in web interfaces are based on well-established definitions and measurements in the literature. Visual complexity refers to the overall “load” on the screen with visual elements and structure. The higher the local variation in features (color, orientation, contrast, texture), the harder it is to differentiate the target from the background. This is formalized by metrics such as feature congestion, subband entropy, and edge density, all of which correlate with subjective assessments of the “clutter” and the time it takes to find a target during visual search tasks. These metrics come from applied psychophysics and computer vision research and are used to objectively assess visual complexity in interfaces without the need for human respondents [6].

Illustrations of algorithms and “congestion” maps demonstrate how feature maps and summary congestion maps are generated from scene images, corresponding to the user’s perception of the complexity of the layout (Figure 1).

Fig. 1. Scheme for calculating visual load with foviation: from feature maps to an integrated map and a PIFC coefficient [4]

The performance of the user experience on the web is measured through the Core Web Vitals, which include Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. These metrics measure the speed of the main content appearing on the screen, the overall responsiveness during user interactions, and the stability of the layout, respectively. The thresholds for these metrics are set at LCP ≤ 2.5 seconds, INP ≤ 200 milliseconds, and CLS ≤ 0.1. These thresholds are measured using the 75th percentile for mobile and desktop devices, and are used for both laboratory and real-world measurements (RUM). The transition from First Input Delay (FID) to Interaction to Next Paint reflects a shift in focus from measuring the initial responsiveness of the page to measuring the overall responsiveness throughout its lifetime [7].

At the structural and technical level, one important aspect is the size and shape of the Document Object Model (DOM): large element trees can increase the cost of styling and event handling, which can impair interactivity. Lighthouse audit reports and practical reviews indicate conditions that trigger a warning about “excessive DOM”, including a total of more than ~1,500 elements, a depth of more than 32 levels in the tree, and a parent element with more than 60 direct children. At the same time, Google’s methodology materials explain how DOM size affects interactivity and describe measurement and diagnostic methods in DevTools [1].

The rendering process involves sequentially building the DOM and CSS Object Model (CSSOM), followed by the creation of the Render Tree. After that, the layout and painting are performed. Figure 2 shows how styles are distributed throughout the document structure and how the render tree is formed. Based on this information, the browser can calculate the position and render the elements.

Fig. 2. DOM, CSSOM, and Render Tree formation in the browser: spreading styles and building a rendering tree [8]

It is more convenient to combine practical measurements of visual complexity and performance into a single metric called “perceptual complexity ↔ technical cost”. A table summarizing the key measurements used in the research and audit of web interfaces allows us to use standardized benchmarks for measuring the quality of user experience and typical structural constraints that affect the computational cost of rendering (Table 1).

Table 1

Key metrics and measurement benchmarks for the concepts of “visual complexity” and “performance”

Source: author’s development

The strategy for improving the speed of the interface is based on progressive rendering. First, the user sees the frame of the block, and areas for the key elements are reserved. Then, as data and media arrive, texts, previews, and final images are added. This approach reduces the user’s expectations, stabilizes the layout, and improves the LCP (first meaningful paint) and overall responsiveness. Expensive media and non-critical widgets are loaded only when necessary. Figure 3 shows how the elements appear in the container, from an empty state to a fully-formed card block.

Fig. 3. Progressive rendering: the evolution of the screen from a “skeleton” and stubs to fully loaded content [3]

The framework model of balance simplifies the task by choosing points on the Pareto front between expressiveness and speed. With a fixed interface goal in mind, the minimally sufficient visual language (hierarchy, typography, media) is first determined. Then, resource budgets and a critical rendering path are set. Priority is given to elements that enhance the usefulness of the first screen and sustain responsiveness.

Complexity is managed by limiting the depth and density of the DOM, adapting the delivery of images and fonts, delaying and splitting JavaScript, and stabilizing the layout by reserving space for media. The impact of each measure is assessed through field and laboratory tests of Core Web Vitals, monitoring the device and network context. Solutions are implemented in the CI/CD pipeline as budgets and automatic thresholds, ensuring balance during product development.

The main categories of strategies in open-source solutions are:

1. Rendering architectures, which render the main content as static HTML and add interactive elements as needed. This reduces the overall JavaScript bundle. The React Server Components approach falls into this category and reduces the client load.
2. Resource supply patterns, such as PRPL (Pre-render initial route, pre-cache, lazy-load) and proportional code loading at the start.
3. Prioritization of network downloads using Fetch Priority and resource hints. 103 Early Hints can be installed on the server to provide hints before the main response.
4. Browser operational optimizations like bfcache for instant “back/forward” navigation and native delayed media loading to reduce real delays during repeated transitions and the loading of off-screen resources.

All of these strategies aim to retain visual expressiveness while making it more “cost-effective” by reducing the amount of client-side JavaScript and delivering the most critical elements as early as possible.

Here is a brief summary of the rules and trade-offs in table 2. It provides precise guidelines for the Core Web Vitals, structural thresholds for the Document Object Model (DOM), characteristic values for the “weight” of media and unused JavaScript in the real world, as well as basic technical rules that affect the perception of speed and sustained responsiveness.

Table 2

Table of threshold considerations for the balance of “visual complexity ↔ performance”

Source: author’s development

To accurately assess the impact of strategies on “response” and smoothness, it is advisable to supplement field CWV telemetry with specialized attribution and frame breakdown APIs. Table 3 provides an overview of additional attribution and diagnostic tools that should be incorporated into the strategy evaluation process.

Table 3

Attribution and diagnostic tools: what we measure and how to measure

Source: author’s development

Considering the available materials, it would be advisable to review the following points regarding products. Firstly, monitoring LoAF in the field allows for a more accurate identification of scripts and areas responsible for “failures” in responsiveness, compared to Long Tasks telemetry alone. The hypothesis is that regular work to “dampen” LoAF spikes leads to a statistically significant improvement in the distribution of INP at P75-P95 [5].

Secondly, excluding @import and explicitly signaling the priority of critical styles/resources at an earlier stage (rather than detecting them later) significantly reduces the proportion of LCP cases where “resource delay” and “resource duration” dominate TTFB. This hypothesis is based on a decomposition of LCP into its subcomponents.

Thirdly, the migration of problematic areas, causing layout thrashing, to read/write batching and more “lazy” update strategies, should reduce the frequency of forced reflow and correlate with a decrease in long frames (LoAF) under user scenarios [2].

Finally, replacing heavy visual connection/injection techniques, such as synchronous script inserts via document.write, with non-blocking alternatives, should reduce the proportion of “late-found” blocking resources and improve early frames. This should be checked, at least, on pages with third-party widgets.

Conclusions. Thus, the balance between expressiveness and speed is achieved not by reducing the quality of the visual language, but through careful management of its “cost”. This includes limiting and structuring the DOM, delivering critical resources early and with priority, localizing interactivity, skipping invisible rendering, and maintaining budget discipline in CI/CD.

The use of attribute tools such as CrUX/RUM, Element Timing, LCP API, and LoAF allows us to associate specific changes (such as media, fonts, JavaScript, and markup) with movement in metrics at the 75th percentile and prevent regressions in the tail. Framework models and strategy taxonomies ensure a predictable “trade-off” between visual effects and responsiveness, leading to a stable layout. Further work should focus on verifying these hypotheses in products and formalizing practical budgets for various domain scenarios, such as content portals, e-commerce, and SaaS.

 References

1. «Avoid an excessive DOM size» returned even when none of the three listed criterea are met. Access mode: https://github.com/GoogleChrome/lighthouse/issues/11746.
2. Avoid large, complex layouts and layout thrashing. Access mode: https://web.dev/articles/avoid-large-complex-layouts-and-layout-thrashing.
3. Critical Rendering Path. Access mode: https://web.dev/articles/critical-rendering-path.
4. Foveated Feature Congestion flow diagram: In this example, the point of… | Download Scientific Diagram. Access mode: https://www.researchgate.net/figure/Foveated-Feature-Congestion-flow-diagram-In-this-example-the-point-of-fixation-is-at-15_fig1_306187523.
5. Long Animation Frames API. Access mode: https://developer.chrome.com/docs/web-platform/long-animation-frames.
6. Measuring visual clutter – PubMed. Access mode: https://pubmed.ncbi.nlm.nih.gov/18217832/.
7. Web Vitals. Access mode: https://web.dev/articles/vitals.
8. When will a browser parse elements which are hidden? – Stack Overflow. Access mode: https://stackoverflow.com/questions/34279992/when-will-a-browser-parse-elements-which-are-hidden/34280126.