[$250] [INP] Slow Receipt-Image interaction

[rlinoz]

In an effort to improve the #quality of our app we started looking at INP (interaction to next pain) and looking at our slowest INPs we have [data-sentry-label=“Receipt-Image”]

Let's investigate why it is slow and fix it.

Issue Owner

Current Issue Owner: @ChavdaSachin

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022034008657026086159
• Upwork Job ID: 2034008657026086159
• Last Price Increase: 2026-06-16

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @thesahindia (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022034008657026086159

[MelvinBot]

I have failed to help you. I let you down and for that I am sorry. Please try again later. This may be due to a Claude outage (check here).

Failure details: https://github.com/Expensify/Expensify/actions/runs/23215681844

[jainam884]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Tapping a receipt image is one of the slowest INP interactions in the app. The interaction tagged as Receipt-Image should open the receipt preview quickly, but users can hit a delayed next paint.

What is the root cause of that problem?

The Receipt-Image interaction is emitted from the pressable that navigates to TRANSACTION_RECEIPT.

App/src/components/ReportActionItem/ReportActionItemImage.tsx

Lines 182 to 197 in 858f99c

	<PressableWithoutFocus
	style={[styles.w100, styles.h100, styles.noOutline as ViewStyle]}
	onPress={() =>
	Navigation.navigate(
	ROUTES.TRANSACTION_RECEIPT.getRoute(
	transactionThreadReport?.reportID ?? contextReport?.reportID ?? reportProp?.reportID ?? getReportIDForExpense(transaction),
	transaction?.transactionID,
	readonly,
	mergeTransactionID,
	),
	)
	}
	accessibilityLabel={translate('accessibilityHints.viewAttachment')}
	accessibilityRole={CONST.ROLE.BUTTON}
	sentryLabel={CONST.SENTRY_LABEL.RECEIPT.IMAGE}
	>

On modal mount, TransactionReceiptModalContent reads useAllTransactions() and then picks one transaction by ID.

App/src/pages/media/AttachmentModalScreen/routes/TransactionReceiptModalContent.tsx

Lines 45 to 47 in 858f99c

	const [report] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${reportID}`);
	const allTransactions = useAllTransactions();
	const transactionMain = allTransactions?.[`${ONYXKEYS.COLLECTION.TRANSACTION}${getNonEmptyStringOnyxID(transactionID)}`];

useAllTransactions() subscribes to the full transaction collection and may rebuild a filtered map from search data before returning it.

App/src/hooks/useAllTransactions.ts

Lines 11 to 38 in 858f99c

	function useAllTransactions() {
	const {currentSearchResults} = useSearchStateContext();
	const [allTransactionsCollection] = useOnyx(ONYXKEYS.COLLECTION.TRANSACTION);
	const allTransactions = useMemo(() => {
	const data = currentSearchResults?.data;
	if (!data) {
	return allTransactionsCollection;
	}
	const filteredSearchTransactions = Object.keys(data)
	.filter((key): key is `${typeof ONYXKEYS.COLLECTION.TRANSACTION}${string}` => key.startsWith(ONYXKEYS.COLLECTION.TRANSACTION))
	.reduce(
	(acc, key) => {
	const value = data?.[key] as OnyxEntry<Transaction> | undefined;
	if (value) {
	acc[key] = value;
	}
	return acc;
	},
	{} as Record<string, OnyxEntry<Transaction>>,
	);
	return {
	...filteredSearchTransactions,
	...allTransactionsCollection,
	};
	}, [currentSearchResults?.data, allTransactionsCollection]);

So the click path does collection-wide work to render a screen that needs one transaction record, which can delay the next paint and inflate INP.

What changes do you think we should make in order to solve the problem?

1. Replace useAllTransactions() in TransactionReceiptModalContent with a direct useOnyx read for the single transaction key (COLLECTION.TRANSACTION + transactionID).
2. Keep existing draft and merge-transaction behavior, but compose it from that single transaction instead of the full collection.
3. Add a narrow fallback path for search-context edge cases: if the single Onyx transaction is missing, resolve only that matching transaction key from search data rather than building a merged map of all transactions.
4. Keep all current modal behaviors unchanged (view, replace, crop, rotate, delete), while removing unnecessary collection-wide work from the Receipt-Image interaction path.

What alternative solutions did you explore? (Optional)

• Deferring navigation or showing a temporary skeleton earlier. This can hide latency but does not remove the heavy data work from the interaction path.
• Micro-optimizing useAllTransactions() internals. This still keeps a full-collection subscription for a single-transaction modal.

[mendarb]

Proposal

Please re-state the problem that we are trying to solve in this issue.

The Receipt-Image interaction has a high INP score. When users tap on a receipt image (e.g., to preview it), the UI is unresponsive for too long before the next paint, creating a poor user experience.

What is the root cause of that problem?

Looking at the component chain ReportActionItemImage → ReceiptImage, several compounding performance issues cause excessive work during the press interaction:

1. Neither component uses React.memo: Both ReportActionItemImage (line 219) and ReceiptImage (line 264) are plain function component exports. In list contexts (report action lists showing multiple receipts), any parent re-render re-renders every receipt image, even when props are unchanged.

2. propsObj rebuilt from scratch every render: In ReportActionItemImage (lines 142-176), the propsObj: ReceiptImageProps object is constructed fresh through a chain of if/else blocks on every render, creating new object references that prevent any future shallow comparison optimization.

3. Inline onPress callback: The PressableWithoutFocus onPress (lines 184-194) is an inline arrow function () => Navigation.navigate(...) — a new function reference every render.

4. tryResolveUrlFromApiRoot called unconditionally in render: Lines 137-138 call tryResolveUrlFromApiRoot(image) and tryResolveUrlFromApiRoot(thumbnail) on every render. While the function is cheap (regex replace), it produces new string references when replacement occurs, creating unnecessary prop changes.

5. onLayout state thrashing in ReceiptImage: The ImageWithLoading path (line 240-245) uses onLayout to call setReceiptImageWidth. The guard uses a timestamp comparison (MIN_UPDATE_WIDTH_DIFF = 1000 milliseconds), not a width-value comparison — so after 1 second, any layout event with a different width triggers a state update and re-render even if the change is trivial.

What changes do you think we should make in order to solve the problem?

1. Wrap both ReceiptImage and ReportActionItemImage in React.memo: This is the highest-impact change — prevents re-renders when parent components update but receipt props have not changed.

2. Memoize propsObj construction: Build the props object inside a useMemo in ReportActionItemImage, depending only on the values that determine which rendering branch is taken (isEReceipt, thumbnail, isLocalFile, isPDF, etc.).

3. Stabilize the onPress handler: Wrap the navigation callback with useCallback so PressableWithoutFocus receives a stable function reference.

4. Memoize URL resolution results: Use useMemo for originalImageSource and thumbnailSource so they produce stable string references across renders.

5. Fix the onLayout guard: Add an early return when e.nativeEvent.layout.width === receiptImageWidth as the primary guard, before the timestamp comparison — avoid the setReceiptImageWidth call entirely when width has not changed.

6. Defer navigation on press: Wrap the Navigation.navigate() call in the onPress handler with InteractionManager.runAfterInteractions() so the press visual feedback paints before navigation begins.

What alternative solutions did you explore? (Optional)

• Lazy-loading the different receipt rendering paths (EReceiptThumbnail, PDFThumbnail, etc.) with React.lazy was considered, but since the conditional rendering already only mounts one path at a time, the overhead is in the decision logic and prop construction, not in mounting unused components.

[melvin-bot]

📣 @mendarb! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[chengyixu]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

📣 @chengyixu! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>