[태그:] App performance

This article does not answer the title’s question. The plan was to test whether changing one image under the same conditions altered the time to complete a scripted task correctly, but no performance measurement of the actual task was run (NOT RUN). Here we explain the fictional catalog, the comparison procedure, and why work stopped before measurement. Even a completed comparison would not establish whether people would find the app usable. A checklist for a separate test environment appears at the end.

Before asking how fast, define “done”

The prepared app contains 120 fictional products. The scripted task is to select the Desk category, wait for the image of product C037 to be ready, add one item to the basket, and open the confirmation screen. The independent completion criteria require Desk to be selected; visible C037 details to match ‘Blue triangle stand,’ price 1200, and ‘In stock’; and its image to be decoded (unpacked for drawing on screen) with nonzero natural dimensions. The basket must contain exactly one C037 row and no other item, with quantity 1, unit price 1200, total 1200 in fictional units, and the visible message ‘Basket confirmed.’ Required assets must not fail and no uncaught app error may occur.

The app’s own “success” signal cannot establish that these conditions hold. Values actually shown on screen need to match expected answers recorded separately from the app. A quick finish with the wrong quantity does not count as completion.

The script contains the target product’s locator; this attempt on the test computer did not demonstrate it finding the rendered product. It does not measure the time a person takes to find and assess it. The timed task includes C037 image readiness by construction, and the preselected candidate reduces that same image. Its proposed 320×240 dimensions equal the planned 160×120 CSS box multiplied by the planned DPR of 2; this arithmetic is not a visual-quality result. Whether the change would save time, by how much, and how well the task matches human use remain unknown. A trace link could still reflect a wait imposed by the protocol. Resizing also changes transfer and decoding conditions together, rather than isolating either mechanism. A link alone would not establish that a person waited for the image or that resizing caused a time difference. Memory effects are not measured separately.

A fast responsiveness metric does not establish correct task completion. Interaction to Next Paint (INP), for example, concerns responsiveness through the next paint after an interaction; it does not mean navigation to another page or completion of every operation that follows. Whether the basket contains the correct item still needs a separate check. INP explained

Record the comparison conditions and the waiting intervals first

The plan was to use the same Mac and Chrome, with a browser viewport of 390×844 CSS pixels, a device pixel ratio (DPR) of 2, and 100% zoom. It also specified a 4× CPU slowdown, 1600 Kbps (kilobits per second) download, 750 Kbps upload, and 150 ms latency. These were design settings, not measurement conditions whose application and effectiveness had been verified. A narrow viewport and throttling (deliberately slowing the CPU and network) do not amount to testing a particular phone. Chrome documents numeric network throttling settings, but that documentation is not proof that they were applied in this environment. Throttling settings

The design separated two procedures for the browser’s HTTP cache—the stored resources it can reuse. The cache-cleared condition clears the HTTP cache and resets task state before entering a fresh document from a neutral page each time. Ordinary caching stays enabled during measurement; this differs from “Disable cache,” which blocks caching throughout. The prepared-before-each-measurement condition follows this sequence: clear the cache for the version being tested → complete one untimed task → reset task state, including the basket, without clearing the cache → enter a fresh catalog document from a neutral page, measure, and verify required-resource reuse. History restoration and bfcache, which restores the previous page as a whole, are excluded. Preparation does not count toward measured runs. The design does not rely on a simple reload to separate the conditions. Server and operating-system caches are not separately controlled, so other warm-up effects may be mixed in.

The timer was designed to start immediately before the navigation command and stop when the runner observed that the full independent basket-completion criteria still held after two animation-frame callbacks. The design checks the completion conditions every 50 ms and includes polling, navigation and action waits, and communication between the automation tool and browser in the elapsed time, while excluding browser launch. The two callbacks offer a rendering opportunity, not proof of physical display timing. Timing verification did not run, so the size of this overhead is unknown. The task limit is 60 seconds. Intervals before and after the target image became ready would also be recorded separately. The interval before the image was ready would not, as a whole, be labelled image download time.

This design calls for checking the records before activating the proposed change. Chrome’s performance recordings let you inspect rendering and execution work over time. A large file alone does not establish that it delayed the task. Performance recording guide

In this design, only a record linking work on C037’s image to the wait would justify changing that one image from 1200×900 to 320×240. Its displayed size would remain 160×120 CSS pixels, with other products, logic, and loading policy unchanged. It would also be necessary to check that the required shapes remained visible in the smaller image. Without that link, comparison with the modified version would not begin. Here, even the diagnostic task was not run, so whether the image was a bottleneck remains unknown.

What preparation checked—and where the attempt on the test computer stopped

On October 15, 2026, the original version A, a modified candidate B prepared but not yet enabled for comparison, an expected-answer file, local server code, and checking tools were prepared. The initial eight offline tests passed. A review step separate from implementation then found that two deliberately faulty cases—adding a quantity of 2 instead of one item, and displaying the wrong completion message—also passed all eight tests, returning exit code 0. Passing those tests did not demonstrate that the actual completion criteria had been checked.

The offline checks were subsequently extended to reject both faults using a simulated page structure. This did not verify layout, image decoding, or clicks in a real browser. The separate review on October 26 likewise allowed only a preparatory check on the test computer; it did not declare the performance task ready to run. Enforcement of all completion criteria in a real browser remained unverified.

One setup check was attempted on the test computer that day, and Chrome launched. Six checks passed for the setup test page: structure, documents, downloads, uploads, cache, and reused data. These setup checks do not establish catalog-task completion, catalog-resource transfer or cache reuse, or effective application of the 4× CPU slowdown and 1600/750 Kbps, 150 ms network profile.

The overall result was a failure. The check matching file transfers in the browser’s performance recording to separately retained network transfer records failed (linked-transfer). That connection is evidence needed to trace which transfers relate to a wait. The cause of the linkage failure remains unknown; this failure alone does not show that Chrome transferred data incorrectly or that the app was slow.

Work stopped at that failure, without the follow-up verification step or a retry. Under the predeclared rule to stop before measurement if this attempt failed, the article’s scope became an explanation of the method. Verification of effective CPU and network throttling, the actual task flow, and other prerequisites was still outstanding. Fixing the trace issue alone would not establish readiness to measure.

What you can still record without results: a checklist

The plan has five measurements per version in each cache condition: cache-cleared first in A1/B1 through A5/B5 order, then prepared-before-each-measurement in B1/A1 through B5/A5 order. This does not eliminate time drift. Every B slot is conditional on an image-path diagnosis and the subsequent checks of the change’s scope, file-hash lock, visual quality, and pilot, which were never completed. The table records unrun planned slots.

B remained disabled for comparison. No task diagnosis, pilot, or cache-priming task was run either. No median, minimum, or maximum exists. Missing values do not mean “0 seconds.”

This design uses a local fictional app, with no real accounts, personal data, or external tracking. The following questions are proposed for a separate non-production test environment with fictional data. They do not call for sharing traces containing real user information or changing network settings on a shared system.

• What must appear on screen and be present in the data for completion to be correct?
• Can the records link the interval that delayed completion to the resource involved?
• Does the proposal make only one change while preserving the original completion conditions and visual information?
• Can repeated attempts use the same device, settings, and cache procedure, with failures retained too?

In this design, for each version and cache condition, retain every planned slot and any labeled replacement, and report attempts, correct completions, timeouts, completion-check failures, and invalid attempts. Keep slow correct results; do not delete outliers or repair and resume the same series. A timeout at the 60-second cap is not a successful 60-second completion. At most one replacement per cell is allowed for an invalid attempt whose transient cause is resolved without changing the protocol; timeouts and slow successes are not replaceable. Fewer than five valid correct completions makes a cell incomplete: any successful-only median and range must state the actual count and cannot support a five-run speedup claim. Compare only within the same cache condition. These summaries are descriptive, not evidence of statistical significance. Five repetitions would not establish effects on a general user population.

Instead of asking an AI tool to “make it faster,” you can ask: “These are the completion criteria. Before changing what looks slow, show evidence for the interval that makes completion wait and what remains unknown. Propose one change when the evidence supports it.” This is a method drawn from the preparation work, not a prescription whose effectiveness has been demonstrated. In this design, if completion criteria and their connection to the wait cannot be established, comparison with the modified version does not begin, and another fix is not substituted within the same comparison. This is the experiment’s stop rule, not a general law for all defect fixes.

AI assisted with research and drafting. The author reviewed the final manuscript and directed the revisions.