How to Use Chrome DevTools to Test a Website at Oppo A-Series Screen Sizes
Test responsive layouts in Chrome DevTools with a reusable mobile profile. Learn why you need the exact Oppo model before choosing viewport dimensions.
To test a website at an Oppo A-series screen size in Chrome, open DevTools, turn on the device toolbar, and enter the target phone’s CSS viewport width and height. Set the device type to Mobile and choose a device pixel ratio (DPR) when those behaviors matter. For a repeatable setup, save the dimensions as a custom device profile.
There is no single Oppo A-series screen size. First identify the exact model and regional variant. A manufacturer’s panel resolution is not automatically the CSS viewport size to enter in DevTools, so confirm the browser dimensions and DPR on that handset or from authoritative model-specific device data.
1. Identify the exact Oppo model
“Oppo A-series” covers phones with different displays. For example, OPPO lists the Egypt-market A60 CPH2631 with a 6.67-inch, 1604 × 720 display; OPPO Global lists the A93 with a 6.43-inch, 2400 × 1080 display; and OPPO India described the A15s as having a 6.52-inch HD+ display. These are panel specifications for distinct products and markets, not verified CSS viewport profiles.
Before creating a device profile, record the model code and market. If you have the phone, inspect the browser viewport and DPR on the device. Otherwise, look for reliable, model-specific browser data. Do not calculate CSS width or DPR from the panel resolution or diagonal alone.
2. Set up the page in Chrome DevTools
- Open the page you want to test in Chrome.
- Open DevTools from Chrome’s menu or with your operating system’s DevTools shortcut.
- In DevTools, click Toggle device toolbar in the action bar. The viewport controls appear above the page.
- Select Responsive if it is not already selected.
- Enter the target model’s verified CSS viewport width and height in the dimension fields. You can also drag the viewport handles for exploratory checks.
Chrome’s standard responsive presets are useful for general coverage: Mobile S is 320 px wide, Mobile M 375 px, Mobile L 425 px, Tablet 768 px, Laptop 1024 px, Laptop L 1440 px, and 4K 2560 px. These are generic test widths, not Oppo-specific dimensions. Use them as a broad smoke test while you verify the handset profile.
3. Save a reusable custom device profile
If you test the same handset often, add a custom device. In the device toolbar, open the device list, choose Edit, then add a custom device. Give it a clear name that includes the model and market, and enter the verified width and height. Set DPR, user agent, and device type if you have reliable values and need to reproduce those conditions.
| Profile field | What to enter | When it matters |
|---|---|---|
| Name | Exact model and regional variant | Prevents a generic profile from being mistaken for a verified handset. |
| Width and height | Browser CSS viewport dimensions | Controls layout, viewport units, and media queries. |
| DPR | Verified device pixel ratio | Useful for high-density images, canvas output, and resolution-dependent CSS. |
| Device type | Mobile for touch behavior | Use when testing touch interactions and mobile rendering. |
| User agent | Only when a verified target value is needed | Some sites branch on user agent; changing it does not reproduce the full phone environment. |
If the exact CSS viewport or DPR is unknown, label the profile as an estimate or leave the value at a deliberate test setting. Do not name an unverified generic viewport “Oppo A60” or imply it reproduces every A-series phone.
4. Choose touch behavior and DPR
Set the device type to Mobile when you need touch events. Chrome’s Mobile (no touch) option keeps mobile rendering while using click events. This distinction can expose issues in menus, swipe gestures, and controls that respond differently to touch.
DPR maps CSS pixels to device pixels. It can affect image selection, resolution media queries, and raster output. Use the model’s known DPR for a closer emulation, or deliberately vary DPR to check that the page handles density changes. DPR does not change the CSS viewport width you entered.
5. Check breakpoints and real interactions
- Open the page’s responsive layout and enable Chrome’s media query display if available.
- Identify the breakpoints used by the site, then test just below and just above each boundary. A layout that works at one width can still fail at the transition.
- Inspect navigation, menus, forms, sticky headers, dialogs, tables, and content that may overflow horizontally.
- Rotate the emulated viewport to landscape and repeat the important interaction checks.
- Capture screenshots for review or regression notes. Keep the viewport and DPR consistent when comparing screenshots.
For performance checks, use DevTools’ CPU and network throttling controls. Chrome’s mid-tier mobile preset simulates fast 3G and CPU at four times slower than normal; low-end mobile simulates slow 3G and CPU at six times slower than normal. CPU throttling is relative to the desktop or laptop running Chrome, not a calibrated Oppo benchmark. Use it to reveal likely bottlenecks, not to claim handset-specific performance.
6. Validate on the actual phone
Device mode is useful for fast layout and interaction checks, but it cannot establish how the page behaves on every phone. Chrome describes it as a “first-order approximation” of how a page looks and feels on mobile. Desktop emulation does not fully reproduce a phone’s CPU architecture, operating system, browser build, fonts, or hardware behavior.
When exact behavior matters, open the page on the target Oppo handset and check the same flows: viewport fit, touch input, orientation, text rendering, media loading, and performance. Treat the actual model and browser as the final validation target.
Emulation and real-device testing compared
| Method | Good for | Limit |
|---|---|---|
| Chrome responsive mode with generic widths | Quickly checking common breakpoints and narrow layouts | Does not identify a specific Oppo handset. |
| Chrome custom device profile | Repeatable viewport, DPR, and touch checks for a known target | Still emulates conditions; it does not recreate all phone software and hardware. |
| Actual Oppo phone | Validating the real browser, operating system, fonts, touch, and device performance | Requires access to the exact model and market variant. |
Troubleshooting
The page does not match the Oppo screen
Cause: The profile uses panel resolution as CSS dimensions, or it represents a different A-series model. Fix: Confirm the exact model and regional variant, then verify the browser CSS viewport and DPR independently.
The custom device is missing from the toolbar
Cause: The profile was not saved, or the device list has not refreshed. Fix: Reopen the device list’s Edit panel, confirm the custom entry is present, save it, and reopen the list.
A menu works with a mouse but not as expected on the phone
Cause: The emulation is using click behavior or the interface handles touch differently. Fix: choose Mobile with touch enabled, exercise the control in Device Mode, then verify it on the handset.
Images look soft or a layout changes unexpectedly
Cause: The DPR is wrong for the target or the page uses density-dependent image or CSS rules. Fix: set a verified DPR and inspect image source selection and resolution media queries; test a second DPR when checking resilience.
The throttled result is much slower than the phone
Cause: CPU throttling scales relative to the host computer and does not model a specific Oppo processor. Fix: use throttling for comparative diagnosis, then measure and inspect the page on the actual phone for device-specific conclusions.
Landscape mode looks cramped despite a correct portrait profile
Cause: The page has a separate issue at short viewport heights or wide aspect ratios. Fix: rotate the viewport, test menus and sticky elements, and inspect height-based as well as width-based media queries.
Performance, reliability, and cost
Chrome DevTools is a convenient first-pass workflow using the browser and devices already available to you. Its emulation is useful for repeatable layout checks, but it is not a substitute for testing browser and hardware behavior on the actual target phone. For dependable regression comparisons, record the exact model, market, viewport, DPR, browser version, and tested flows alongside screenshots.
The core workflow uses Chrome DevTools and does not require a screenshot service. If your work also needs repeatable captures of public pages, an API can avoid maintaining browser automation. ScreenshotNeo offers a website screenshot API and MCP server; its options include custom viewports and device presets. See the ScreenshotNeo site for product details.
Or skip the browser setup
ScreenshotNeo can capture a URL with one GET request. For documentation pages, marketing pages, or other public URLs you want to review, use the API’s viewport and capture options in place of setting up a browser capture script. This API call does not emulate the exact Oppo browser, operating system, fonts, or hardware, so use the DevTools workflow and the real phone for handset-specific validation.
See the ScreenshotNeo API documentation for request options. Example using cURL:
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webpScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before capture; bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000 screenshots.
Sign up for 1,000 free screenshots a month, with no card required.
FAQ
What screen size should I use for an Oppo A-series phone?
Use the verified CSS viewport dimensions for the exact model and regional variant. A-series panel specifications are not a universal browser profile.
Can I use the A60 display resolution as my DevTools width and height?
No. OPPO lists the Egypt-market A60 CPH2631 panel as 1604 × 720, but that physical display resolution does not by itself establish the browser’s CSS viewport or DPR.
Will Chrome DevTools reproduce ColorOS exactly?
No. It approximates mobile rendering and input behavior. Validate on the target phone when operating system, browser, font, or hardware behavior matters.
Should I test generic widths too?
Yes. Generic widths help find responsive layout problems and breakpoint boundaries, but label them as generic checks rather than Oppo-specific profiles.
Sources
- Chrome for Developers: Simulate mobile devices with device mode — device toolbar, custom devices, responsive presets, touch, DPR, throttling, screenshots, and emulation limits.
- OPPO Egypt: A60 specifications — CPH2631 display specifications.
- OPPO Global: A93 — A93 display example.
- OPPO India: A15s announcement — A15s display example.
