{"id":"12a102b8-e035-4973-a793-2ab026d8a0cd","arxiv_id":"2412.07892","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":1.0,"correctness_risk":"low","formal_verification":"none","parameter_count":0,"one_line_summary":"A narrative review cataloging currently available web performance optimization techniques and how web frameworks adopt them, with no new results or data.","lead":"This paper surveys the current techniques for speeding up web applications, from caching and compression to HTML-first development and local-first software. It gives developers a compact map of the field, but it is a narrative review without new measurements or a systematic methodology.","discovery_kind":"review","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The conclusion's claim that Google's Core Web Vitals 'provide a good approximation' of web performance is asserted without empirical support, and the review's scope and technique selection are filtered through this unvalidated premise.","rationale":"The reader's weakest assumption correctly identifies the Web Vitals proxy as the central load-bearing premise. The paper's research question is a descriptive question; its answer should be broad. By narrowing performance to Google's metrics, the paper risks omitting other performance dimensions and techniques that target them. I checked the cited sources: [78]-[83] are web.dev articles explaining metric definitions, not empirical validations of the proxy. Thus the conclusion overstates. A meta-analysis of existing validation research would settle whether the proxy has empirical legs. This does not change the reader's CONDITIONAL verdict; it reinforces it. I find no other internal inconsistency as critical: the paper acknowledges its list is likely non-exhaustive (Table 3 note), so completeness is not claimed. The methodology is informal but appropriate for a narrative overview; the unsupported empirical claim is the weak spot.","tokens_in":13561,"tokens_out":7408,"duration_ms":73109,"concrete_test":"Conduct a systematic meta-analysis of peer-reviewed studies (e.g., from ACM/IEEE conferences and journals) reporting correlations between Core Web Vitals (LCP, INP, CLS) and user experience (satisfaction, task success) or business outcomes (conversion, engagement). Using a random-effects model, compute the pooled effect size and 95% CI. If the pooled correlation is not statistically significant or is < 0.2 in magnitude, the premise that Web Vitals 'capture the main aspects' would lack empirical support. To make the test tractable, limit to studies with at least 1,000 participants or sites and exclude those authored by Google without independent replication.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central answer to 'what are the currently available ways for improving web application performance' is organized around Google's Core Web Vitals, stated in §2.1 as 'they capture the main aspects of web application performance' and repeated in the Conclusion as 'provide a good approximation.' This premise is load-bearing because it defines what counts as a performance improvement and thus determines which techniques are included (e.g., the emphasis on LCP, INP, CLS, TTFB and the focus on loading, responsiveness, and visual stability). Yet no evidence is offered for the approximation claim: the cited sources [78]-[83] are metric definition pages, not validation studies linking Web Vitals to user experience, task success, or business outcomes. If the proxy is wrong or incomplete—e.g., omitting energy consumption, memory use, accessibility, or server cost—then the enumerated techniques may not be the 'currently available ways' to improve performance in a broad sense; they are only ways to improve a particular vendor's metrics. The conclusion elevates this assumption to 'the core of it all,' so its failure would undermine the review's scope and the usefulness of its answer.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper is a narrative overview of techniques for improving web application performance. It frames the topic through Google's Core Web Vitals, presenting LCP, FCP, FID, INP, CLS, and TTFB as the relevant metrics (§2.1, Table 1), and discusses latency, transport protocol, offloading work, caching, and several modern development approaches including progressive enhancement, HTML-first development, utility-first styling, HTML-first state management, local-first software, partial loading, performance tooling, dead code elimination, and compression (§3). It then surveys how web frameworks relate to these techniques (§4, Table 4) and concludes that there are many available ways to improve performance and that Web Vitals provide a good approximation of web performance (§6).","tokens_in":13752,"tokens_out":5310,"duration_ms":51907,"significance":"If corrected, the paper would be a useful and accessible synthesis for practitioners and researchers who want a compact map of current optimization directions. Its strengths are the breadth of recent topics covered, the useful summary tables, and the inclusion of current support statistics and evolving standards (e.g., Brotli, WebP, INP). It does not claim new empirical results and explicitly notes that its list is likely non-exhaustive. However, the paper's organizing premise is not sufficiently supported: the identification of Core Web Vitals is factually imprecise, and the claim that they approximate web performance is asserted without empirical backing. Because the scope of the survey depends on this premise, the manuscript needs revision before the synthesis can be fully relied upon.","major_comments":[{"comment":"The statement that 'Google evaluates the following six parameters known as Core Web Vitals to rank site speed: LCP, FCP, FID, INP, CLS, and TTFB' is inaccurate. Google's Core Web Vitals are LCP, INP, and CLS; the others are Web Vitals but not part of the Core Web Vitals set. Since the paper organizes its entire scope around this notion, the error is load-bearing and should be corrected, with Table 1 and the surrounding discussion aligned to the actual distinction.","section":"§2.1 and Table 1"},{"comment":"The claim that Core Web Vitals 'capture the main aspects of web application performance' and later 'provide a good approximation' of performance is a load-bearing assumption, but the cited sources [78]–[83] are metric documentation pages, not empirical validation studies linking these metrics to user experience, task success, or business outcomes. Please either add supporting evidence or explicitly reframe this as a working assumption, and acknowledge performance aspects not covered by Core Web Vitals (such as energy consumption, memory footprint, accessibility, and server-side cost).","section":"§2.1 and Conclusion (§6)"},{"comment":"The paper poses a research question about 'currently available ways' to improve web performance, but no literature search or inclusion methodology is described. The resulting coverage is therefore a narrative selection rather than a systematic answer, and this limitation is only implied by the statement that the list is non-exhaustive. Please add a brief methodological note in the Introduction or Discussion that acknowledges the non-systematic nature of the survey and the risk that relevant techniques or studies may be under-represented.","section":"Introduction and Discussion"}],"minor_comments":[{"comment":"The 'Related examples' cell lists '[24]' where the text in §3.9 correctly names 'gzip [24]'; please fix the table entry to name gzip explicitly.","section":"Table 3, Compression row"},{"comment":"The phrase 'can be considered an obsolete [80]' is ungrammatical; it should read 'can be considered obsolete [80]'.","section":"Table 1, FID row"},{"comment":"The venue name 'Lecture Notes in Business Processing (LNBIP)' is a typo; the correct name is 'Lecture Notes in Business Information Processing'.","section":"First page note"},{"comment":"The statement that generated CSS from utility-first styling is 'generally a tiny amount compared to conventional techniques according to our experience' presents a personal observation as a general claim; please mark it explicitly as the authors' experience or add a supporting reference.","section":"§3.3"},{"comment":"The transition 'Developers exist at the other extreme' is confusing; rephrase to clarify the developer's position in the workflow described by Figure 1.","section":"§2.6"},{"comment":"The page range '291–401' appears implausibly long; please verify and correct the page numbers for the SANER 2018 paper.","section":"Reference [50]"}],"recommendation":"major_revision","confidential_remarks":"The manuscript appears to be a previously published LNBIP paper posted as a preprint. If the journal intends to publish it as a new submission, the editors should clarify the relationship with the prior publication and the expected novelty. The paper is more of a practitioner-oriented survey than an original research contribution, but if such surveys are in scope, the main revision needs are the Core Web Vitals correction and the reframing of the Web Vitals proxy assumption."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"This is a competent narrative review, not a research contribution. It organizes the current web performance toolbox into a clear map: rendering approaches, HTML-first development, utility-first styling, HTML-first state management, local-first software, partial loading, tooling, DCE, and compression. The tables (especially the framework adoption table) are genuinely useful for someone entering the area. It is current, citing 2023-2024 work, and it does a good job of connecting the authors' earlier work on disappearing frameworks and resumability to broader trends. I came away with a decent picture of where the field stands.\n\nThe soft spots are real but modest. The reader's worry about Core Web Vitals as an unvalidated proxy is not fatal: the paper explicitly says it will focus on those metrics because they are what many developers use, and it notes that the metrics evolve. That is a scoping choice, not a hidden assumption. The bigger issue is that the technique selection is not justified by any stated methodology; the list is simply what the authors found. A sentence acknowledging that the selection is based on their reading of the field would have been enough. There are also small presentation slips: Table 3 lists '[24]' instead of naming gzip, and the LNBIP note contains a typo. The self-citations are appropriate because the authors are citing their own prior work on exactly these topics, and the claims are descriptive rather than load-bearing.\n\nWho is this for? Practitioners who want a quick map of what can be done, educators assembling a module on web performance, and researchers who want a compact update before diving into specific techniques. It does not present new measurements or artifacts, so it should not be judged as an empirical contribution. The writing is clear and the reasoning is coherent.\n\nI would accept it for peer review, but with the expectation that a referee asks for a brief statement about how the technique list was assembled and for a slight qualification of the Web Vitals claim (e.g., 'for the purposes of this review' or 'in the context of search rankings'). The paper is worth publishing as an overview; it just needs some tightening.","headline":"A solid, current narrative review of web performance techniques; the Core Web Vitals premise is explicit rather than hidden, so the main soft spot is the lack of a stated selection methodology, not the premise itself.","tokens_in":14302,"tokens_out":1231,"would_cite":false,"duration_ms":14567,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper finds surprisingly many ways to speed up web applications and maps them against Google's Core Web Vitals.","keywords":["web application performance","Core Web Vitals","progressive enhancement","local-first software","partial loading","dead code elimination","compression","web frameworks"],"falsifier":"A concrete check would be to measure a set of real web applications where Core Web Vitals are good but users report poor experience or business conversion is low, or where a technique that improves a non-Vital aspect such as offline capability or battery usage worsens Vitals. Such cases would show that Core Web Vitals are not a complete proxy for web performance as experienced by users.","tokens_in":13353,"feed_emoji":"⚡","tokens_out":3611,"duration_ms":34736,"temperature":0.7,"pith_summary":"This review asks what ways are currently available for improving web application performance, and answers that there are surprisingly many. It organizes the options around four performance aspects—server latency, transport protocol, offloading work, and caching—then surveys nine technique families: progressive enhancement, HTML-first development, utility-first styling, HTML-first state management, local-first software, partial loading, performance tooling, dead code elimination, and compression. The paper argues that Google's Core Web Vitals provide a good approximation of what web performance means, and that web frameworks both codify best practices and risk staying conservative. If the review is right, developers have a structured map of existing levers, and frameworks can be compared by which levers they build in.","feed_headline":"There are surprisingly many ways to speed up web apps","feed_subtitle":"The review maps HTML-first, local-first, partial loading, and compression, with Core Web Vitals as the yardstick.","key_machinery":"The organizing mechanism is a classification: a table of performance aspects (server latency, transport protocol, offloading work, caching) paired with a table of technique families (progressive enhancement, HTML-first development, utility-first styling, HTML-first state management, local-first software, partial loading, performance tooling, dead code elimination, compression). Google's Core Web Vitals serve as the yardstick, defining which performance targets the techniques are evaluated against. The client-server request flow, with caching possible at each stage, is the architectural picture that ties the aspects together.","core_discovery":"The central claim is that the currently available ways for improving web application performance are numerous and diverse, and that Google's Core Web Vitals give a good approximation of the performance aspects these techniques target. The survey treats performance as multifaceted, covering loading speed, interactivity, visual stability, and time to first byte, and it catalogs techniques that range from markup-first development strategies to moving work off the main thread, deferring code, eliminating dead code, and compressing payloads. It also observes that frameworks influence how—and whether—these techniques reach developers, since mainstream frameworks may favor developer experience over user experience while newer 'disappearing frameworks' push performant defaults.","pith_inferences":["Editorial inference: the paper's own Pareto remark hints that a small set of levers—likely payload size and render-blocking—accounts for most practical gains; this could be tested by measuring the marginal contribution of each technique family on a benchmark corpus.","Editorial inference: if Core Web Vitals are not a complete proxy for user experience, techniques that improve non-Vital aspects such as offline behavior, battery use, or perceived responsiveness may be underweighted in framework adoption.","Editorial inference: the 'what you measure is what you get' observation suggests that search-engine visibility creates evolutionary pressure on both frameworks and techniques, so changes to the metrics could steer the entire web platform's direction.","Editorial inference: the local-first shift carries consequences beyond latency, including data ownership and privacy, which the paper notes but does not develop into evaluation criteria."],"forward_implications":["Developers can choose from at least nine distinct optimization directions, several of which are compatible and can be combined without abandoning an existing stack.","Frameworks can be assessed by which techniques they bake in—rendering approach, partial loading, tooling, dead code elimination, and compression—rather than by brand or popularity.","Because the review treats performance as multidimensional, improving one Core Web Vital does not guarantee improvement in another, so optimization must be metric-aware.","The shift from FID to INP in Core Web Vitals shows that the measuring standard itself changes, which will redirect where optimization effort is spent.","The survey's list is explicitly non-exhaustive, suggesting that new techniques will keep reshaping the performance landscape."],"supporting_citations":[{"why":"Defines the six Core Web Vitals used as the review's organizing performance yardstick.","marker":"[83]"},{"why":"Introduces local-first software, a technique family centered on shifting responsibilities from server to client.","marker":"[37]"},{"why":"Provides the streaming-oriented view of transport protocols and the render-blocking problem that motivates HTML-first approaches.","marker":"[76]"},{"why":"Supplies the rendering approaches (SSR, CSR, DPR, ISR, SSG) and the caching-at-each-stage architecture.","marker":"[73]"},{"why":"Establishes the disappearing-frameworks trend that frames the discussion of framework impact on performance.","marker":"[70]"},{"why":"Introduces resumability, which underpins HTML-first state management and granular partial loading.","marker":"[71]"},{"why":"Presents Waiter and AUTRATAC, concrete examples of performance tooling that delays code execution.","marker":"[77]"},{"why":"Documents the near-600% growth in median mobile page weight, motivating the review's focus on size-related techniques.","marker":"[31]"}],"fun_headline_variants":["Web performance review: many levers, one yardstick","Core Web Vitals guide the many paths to faster web apps","Frameworks shape which speed tricks reach your app","From markup-first to off-main-thread: speeding up the web"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The review's map is only as good as the premise that Google's Core Web Vitals capture the main aspects of web application performance, a premise the paper states but does not empirically defend.","fun_headline_variants_meta":{"raw":{"variants":["Web performance review: many levers, one yardstick","Core Web Vitals guide the many paths to faster web apps","Frameworks shape which speed tricks reach your app","From markup-first to off-main-thread: speeding up the web"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000296,"raw_usage":{"total_tokens":1623,"prompt_tokens":755,"completion_tokens":868,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":371,"completion_tokens_details":{"reasoning_tokens":799}},"tokens_in":371,"tokens_out":868,"duration_ms":6607,"temperature":1.0,"reasoning_tokens":799,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-11T18:26:00.745895+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"A concrete check would be to measure a set of real web applications where Core Web Vitals are good but users report poor experience or business conversion is low, or where a technique that improves a non-Vital aspect such as offline capability or battery usage worsens Vitals. Such cases would show that Core Web Vitals are not a complete proxy for web performance as experienced by users.","supporting_citations":[{"cited_title":"https://web.dev/articles/vitals (2024), [Accessed 12-02- 2024]","cited_arxiv_id":null,"evidence_quote":"Defines the six Core Web Vitals used as the review's organizing performance yardstick."},{"cited_title":"In: Proceedings of the 2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software","cited_arxiv_id":null,"evidence_quote":"Introduces local-first software, a technique family centered on shifting responsibilities from server to client."},{"cited_title":"In: Companion Proceedings of the ACM Web Conference 2023","cited_arxiv_id":null,"evidence_quote":"Provides the streaming-oriented view of transport protocols and the render-blocking problem that motivates HTML-first approaches."},{"cited_title":"In: WEBIST 2023: 19th International Conference on Web Infor- mation Systems and Technologies","cited_arxiv_id":null,"evidence_quote":"Supplies the rendering approaches (SSR, CSR, DPR, ISR, SSG) and the caching-at-each-stage architecture."},{"cited_title":"In: International Conference on Web Engineering","cited_arxiv_id":null,"evidence_quote":"Establishes the disappearing-frameworks trend that frames the discussion of framework impact on performance."},{"cited_title":"IEEE Access (2024)","cited_arxiv_id":null,"evidence_quote":"Introduces resumability, which underpins HTML-first state management and granular partial loading."},{"cited_title":"(eds.) Web Engineering","cited_arxiv_id":null,"evidence_quote":"Presents Waiter and AUTRATAC, concrete examples of performance tooling that delays code execution."},{"cited_title":"https://almanac.httparchive.org/en/2022/page-weight (2022), [Accessed 28-08-2023]","cited_arxiv_id":null,"evidence_quote":"Documents the near-600% growth in median mobile page weight, motivating the review's focus on size-related techniques."}],"review_version":1}