Responsive design does not automatically make a website easy to use on a phone. A website can resize correctly yet remain slow, overflow horizontally, shift during loading, or prevent users from submitting a form. A reliable approach is to measure the current state, fix issues according to their impact, and retest both performance and real-world tasks.
The implementation path is: choose representative URLs → measure with tools and real devices → fix the layout and tasks → optimize resources → check mobile SEO → measure again and save the results. This guide applies to custom HTML/CSS websites, CMSs, and WordPress; menu names may vary by platform.
Before making changes, define what success looks like
For each important page, users should be able to:
- Read the heading, main content, and call to action without zooming or scrolling horizontally.
- Tap links, buttons, menus, and form fields without accidentally pressing a neighboring element.
- View content, images, videos, and important data equivalent to what is available on the desktop version.
- Open the page on a less-than-ideal mobile connection without waiting too long or seeing the layout shift repeatedly.
- Complete the primary task, such as reading an article, submitting a contact request, signing in, or making a purchase.
Google uses a website’s mobile version for indexing. Therefore, the mobile version should not hide important content, links, structured data, or metadata simply to make the page shorter (according to Google Search Central).
If you are not familiar with website optimization in general, see the beginner’s guide to SEO and website optimization to distinguish technical optimization from content optimization.
Measure the current state before making changes
Create a list of 3–5 representative URLs: a high-traffic homepage or landing page, an image-heavy article or category page, a product/service page or conversion form, and a URL that has been reported as slow. Record the measurement date, device or emulated configuration, observed issues, and tasks tested.
Open each URL in PageSpeed Insights, select Mobile mode, and save the results. The tool may show real-user data from the Chrome User Experience Report alongside Lighthouse lab data; differences between the two sets of metrics are normal (according to developers.google.com).
| Category | What to record | Meaning |
|---|---|---|
| Display | Horizontal overflow, small text, difficult-to-open menus | Identifies responsive-design and usability issues |
| Performance | LCP, INP, CLS, and response time | Assesses main-content loading, responsiveness, and layout stability |
| Resources | Large images, JavaScript, render-blocking CSS | Finds causes of increased data transfer or processing time |
| Tasks | Menus, forms, sign-in, checkout | Determines whether the website actually enables users to complete its intended goal |
Core Web Vitals currently consist of LCP, INP, and CLS. At the 75th percentile, the reference thresholds are no more than 2.5 seconds, 200 milliseconds, and 0.1, respectively; these thresholds assess user experience and do not guarantee the experience of every user (according to web.dev).
Fix the layout using a mobile-first approach
Mobile-first means building the basic layout for narrow screens first, then expanding it with media queries as the screen becomes wider. This is not a reason to ignore desktop; you still need to test both screen groups.
Check the viewport and embedded media
Where to make the change: the shared HTML file, the CMS template, or the configuration area inserted into the <head>If the website already has a similar tag, do not add a duplicate; check its value first.
<meta name="viewport" content="width=device-width, initial-scale=1">
This tag tells the browser to use the device's actual width. Do not add user-scalable=no or maximum-scale=1 solely to disable zooming, as this can make the site more difficult to use for people with visual impairments.
In the main CSS file, you can start with the following configuration:
img,
video,
iframe {
display: block;
max-width: 100%;
height: auto;
}
.container {
width: min(100% - 2rem, 72rem);
margin-inline: auto;
}
After saving, reload the page with a hard refresh or clear the build system/CMS cache, then check whether images and videos stay within their containers. Do not use overflow-x: hidden to conceal overflow problems; find the element causing the problem in DevTools instead, because this property can hide content.
Reflow multi-column layouts on narrow screens
.layout {
display: grid;
grid-template-columns: 2fr 1fr;
gap: 2rem;
}
@media (max-width: 48rem) {
.layout {
grid-template-columns: 1fr;
gap: 1rem;
}
}
Set the breakpoint where the content starts to feel cramped, buttons wrap awkwardly, or a secondary column interferes with the task; do not choose it solely based on one phone model. In DevTools, resize the window narrower and wider and verify that there is no horizontal scrolling at intermediate widths.
Improve typography, touch targets, and forms
An interface can still be difficult to use even without horizontal overflow if the text is too small, links are too close together, or error messages are unclear. Test with the website's actual fonts, not just placeholder text.
- Use a readable base font size; avoid setting all text to an excessively small fixed size.
- Use a line height of approximately 1.4–1.7 for ordinary paragraphs, then test it with real content.
- Give buttons and links sufficiently large touch targets, and do not place multiple controls too close together.
- Do not use color alone to indicate errors or states; add meaningful text or icons.
- Label input fields clearly and select an appropriate keyboard type.
<label for="email">Email công việc</label>
<input
id="email"
name="email"
type="email"
autocomplete="email"
required
>
Place the code above in the form's HTML, replacing the label text and value name with the values required by your data-processing system. After deployment, test submitting both valid and invalid data; the expected result is that users can identify which field is invalid, why it is invalid, and how to correct it. Also test with a keyboard so that mobile optimization does not introduce an accessibility problem.
Optimize images and downloadable resources
The goal is not to make every image blurry, but to deliver the appropriate dimensions, format, and quality for its display location.
Use responsive images
Where to make the change: the template or the image element's HTML editor. Replace the filenames in the example with the actual files created at 400, 800, and 1,200 pixels; make sure these files exist on the server.
<img
src="anh-800.jpg"
srcset="anh-400.jpg 400w,
anh-800.jpg 800w,
anh-1200.jpg 1200w"
sizes="(min-width: 48rem) 50vw, 100vw"
width="1200"
height="800"
alt="Mô tả ngắn gọn nội dung của ảnh"
>
srcset provides multiple versions, while sizes describes the expected display width. width and height reserve space in advance, helping limit layout shifts when the image finishes loading (according to web.dev). After saving, open DevTools in Mobile mode, reload the page, and check the Network panel to see which image file was actually selected.
Use lazy loading selectively
For images below the initial viewport, you can use:
<img
src="bai-viet-800.jpg"
width="800"
height="533"
loading="lazy"
decoding="async"
alt="Mô tả ảnh"
>
Do not apply loading="lazy" mechanically to hero images or large images that form the initial main content. After making the change, check when the main image appears and review LCP. If the website uses WordPress, see how to convert GIFs to video to reduce file size when a large animated GIF is increasing the amount of data downloaded.
Reduce CSS, JavaScript, and third-party code

After optimizing images, review the resources that require the browser to download or execute substantial amounts of code before users can see and interact with the content.
- Remove unused CSS and JavaScript; do not merely minify them.
- Load only the code required for features used on the current page.
- Defer widgets, ads, chatbots, and analytics tools that are not needed for the initial rendering.
- Keep the main content in HTML that crawlers can read; do not require users to click or swipe before it loads.
- Reduce the number of unused font variants; consider
font-display: swapafter checking for font-display swaps.
Do not remove JavaScript merely to improve a test score if the menu, cart, checkout, or forms stop working. Third-party code should also be assessed for privacy, security, provenance, and data-access implications; do not insert scripts from unknown sources. The article choosing a lighter interface for low-powered devices may help assess the interface and its resources.
Check content and SEO on the mobile version
For responsive websites that use the same URL, administration is generally simpler. If the website serves different HTML by device or uses a separate mobile URL, compare them carefully because the risk of discrepancies in content and metadata is higher.
- Compare the title, meta description, robots directives, canonical, internal links, and structured data between mobile and desktop.
- Make sure the main content, headings, images, alt text, and important videos are available on mobile.
- Do not block CSS, JavaScript, or images required in
robots.txtif Google needs them to render the page. - Do not place the main content behind an action that crawlers cannot perform, such as requiring a click or swipe before it loads.
- Use URL Inspection in Google Search Console to check whether the URL can be crawled and rendered.
Accordions or tabs can save space, but important content must still be present in the mobile version. If you change a template or plugin, back it up first and deploy to a staging environment if available; if the content, menu, or forms break, restore the previous version and then identify the change that caused the problem.
Test on real devices and verify after changes
DevTools helps identify problems but cannot fully replace a real phone. Test at least one small screen, one larger screen, and a moderately paced mobile connection. Perform the following steps on the selected URL:
- Open the URL in a private window to reduce the influence of cached data or browser extensions.
- Scroll from top to bottom; observe images, ads, videos, sticky headings, and elements that load additional content.
- Try rotating the device to landscape if the page contains tables, charts, or a multi-column interface.
- Open the menu, search, sign-in, forms, shopping cart, or primary task flow.
- Deliberately enter invalid data to test the error messages and recovery process.
- In Chrome DevTools, enable slow-network emulation and check the Console for JavaScript errors; then repeat the task on a real device.
After each group of changes, rerun the same URL and task measured at the start. Compare LCP, INP, CLS, load time, Console errors, and task completion; do not draw conclusions from a single score.
Prioritize fixes and maintain a rollback path
- Task-blocking issues: buttons cannot be tapped, menus do not open, forms cannot be submitted, content is obscured, or the page overflows horizontally.
- Content and SEO issues: key content, headings, links, images, alt text, or structured data are missing on mobile.
- Visual issues: text is difficult to read, spacing is cramped, images are distorted, or the layout shifts.
- Performance issues: images are too large, third-party scripts are slowing the page, unnecessary CSS or JavaScript is loaded, or the server responds slowly.
- Advanced optimization: Improve caching and resource delivery, split code, and use selective preloading only after you have performance data.
Before modifying templates, CSS, plugins, or optimization settings, back up the files and database according to your platform’s procedures, record the current version, and deploy changes in small groups. If an error appears, roll back the group just deployed; if the cause is unclear, disable each newly added optimization one at a time instead of deleting everything at once. After restoring the previous state, verify the menu, forms, sign-in, checkout, content, and measurement results again.
Acceptance checklist
- There is no horizontal scrolling at the tested viewport widths.
- Headings, paragraphs, and primary buttons are easy to read and tap.
- Images use appropriate dimensions, suitable alt text, and width and height attributes where appropriate.
- Images below the initial viewport are lazy-loaded; primary content images are not incorrectly deferred.
- The menu, search, forms, sign-in, and conversion flows work on a real device.
- Important content, metadata, links, and structured data are not missing on mobile.
- PageSpeed Insights has been checked in Mobile mode, with real-user data distinguished from simulated data.
- Before-and-after results have been saved, and you know how to roll back the changes if a task stops working.
No fixed PageSpeed score can replace observing users complete a task. The target outcome is for users to read, tap, enter information, and complete what they came to the page to do with fewer errors.
Reference source
- Mobile-first Indexing Best Practices — Google Search Central.
- About PageSpeed Insights — Google for Developers.
- Web Vitals — web.dev.
- Responsive images — web.dev.
- Using responsive images in HTML — MDN Web Docs.
- Lazy loading — MDN Web Docs.

