Why AMP pages lose speed on mobile
AMP pages were conceived as a guaranteed fast format for mobile search results, but in practice the acceleration is lost already at the stage of integration with the main site.
The reason is that the AMP wrapper does not cancel out errors in content and connections: third-party counters, chats, and widgets attach to the page with regular tags and again become blocking scripts.
The browser halts document parsing until it loads and executes them — and all the benefit of the lightweight framework is gone.
The second source of degradation is images. In AMP they are served through a specialized component that reserves space for the image and lazy-loads it.
If this component is bypassed with a third-party tag or a full-size file is served without adaptive variants, mobile speed drops: the page jitters during loading, and the time to render the main content grows.
The same goes for fonts and styles — critical CSS that isn't inlined and the loading of external typefaces block the first render.
The third reason is the lack of loading priorities. When all resources are requested simultaneously and with equal weight, the browser spends time on secondary things: analytics, banners, hidden blocks.
Load optimization begins with what is visible in the first screen — the rest is deferred. Without prioritization, even a correctly assembled AMP page loses on metrics to regular, well-optimized markup.
Caching and delivery deserve separate mention. If the AMP version lives on a separate subdomain without a shared cache policy, a visitor coming from mobile search results gets a cold server response.
Consistent caching headers, compression, and correct static delivery bring back the seconds that are lost on repeated requests.
All these causes are fixable, and we'll break down how this is addressed at the level of the build, priorities, and delivery.
What translating a site to AMP markup delivers
AMP markup removes everything that prevents a page from appearing on screen immediately: heavy scripts, external blocks, deferred loading of the main content.
The browser receives pre-prepared markup and renders the first screen without waiting for third-party requests — time to first render on mobile networks is cut by multiples, not by percentages.
For a visitor, this is the difference between "opened instantly" and "the spinner is spinning."
Then the effect compounds. When the first screen appears quickly, some people don't get a chance to leave: the bounce rate drops because the person doesn't abandon the page while waiting.
This is most noticeable where the audience comes from phones and on an unstable connection — that is, across the majority of mobile traffic.
A separate layer is fast delivery in search results. Pages built according to AMP requirements get into the accelerated display block in search results, where the content opens without fully loading the site.
The share of such pages grows, and search referrals begin arriving at a prepared version rather than a "raw" one.
Importantly, this is not a separate twin site. The canonical address stays the same, the regular and AMP versions reference each other, so the accumulated page weight and rankings are not lost.
If the markup deviates from the requirements somewhere, the page simply drops out of accelerated display — the rest of the site keeps working as before.
Load acceleration here is not a one-time fix but a mode: templates, styles, and loading logic are locked down within the rules, and new pages are built according to them right away. That's why the gain holds rather than disappearing after the first rebuild.
AMP implementation options: comparing approaches
The choice of approach determines not only loading speed, but also how the site lives on afterward: how many page versions will have to be maintained, how difficult it is to make edits, and how search results will behave when content is updated.
Below are three working options that are actually chosen between on projects, with their strengths and the cost of maintenance.
| Option | When it fits | Limitations |
|---|---|---|
| Separate AMP pages | Content sections: articles, news, product cards, where instant visibility in search matters | Two versions of each page — edits need to be synchronized; a reduced set of elements, its own rules for scripts and styles |
| Hybrid markup | One content, two search results: a regular page and its AMP version from the same address | Requires careful linking between versions and control of canonical links, otherwise the search engine will choose the wrong page |
| Dynamic AMP components | Interactive blocks inside AMP: filters, lazy loading, forms, feeds | Logic is limited to the allowed set of components; non-standard scenarios have to be rewritten to fit AMP rules |
In practice, hybrid markup is most often chosen: it provides a fast AMP version without duplicating content and without a second set of edits.
Separate pages are justified when AMP is needed selectively — for example, only for articles, while the rest of the site lives its own life. Dynamic components are connected on top of any of the options when the AMP version needs filters or lazy loading, rather than just text.
AMP limitations are not a verdict, but a framework to design for in advance: the set of allowed tags, the ban on arbitrary scripts, requirements for styles and markup.
If you account for them at the design stage, rather than bolting AMP onto a finished site, the cost of maintenance drops: edits go to a single source, and the fast version is assembled automatically.
We finalize the choice of approach after analyzing the site structure and scenarios: where search speed is needed, where interactivity is needed, and where a single content source matters more. Describe the task — we will come back with an estimate and a plan for the specific option.
How We Implement AMP: Stages of Work
Implementing AMP is not about "installing a plugin" but about restructuring the output and markup so that every page passes validation and is served from cache instantly.
We start with an audit: we look at which page types even make sense in AMP (articles, product cards, landing pages), which scripts and third-party embeds break them, and where duplicate mobile versions already exist.
Based on the audit results, we fix the list of templates and constraints — this saves weeks of rework later on.
Then the process proceeds in stages, and each one has a clear deliverable that can be verified.
- Audit of the current markup. We analyze the page structure, find invalid HTML, heavy third-party scripts, inline styles, and blocks that AMP prohibits. The output is a page map and a list of what will have to be rewritten.
- Designing AMP templates. We assemble a set of templates for each content type: article, catalog, product card, landing page. We pre-build in the components allowed in the markup and the analytics integration points.
- Setting up caching. We configure static asset delivery and markup so that pages correctly enter the search engine cache and update on publication. Here we also decide how to synchronize the AMP version with the main one.
- Validation. We run every page through the validator, eliminating errors and warnings. The goal is zero critical errors: otherwise the page will not make it into fast search results.
- Deployment and handover. We roll out to production, check indexing, and provide the team with documentation on templates and the rules for adding new pages.
The key point is synchronization: the AMP version must not live separately from the main one. We link them with canonical URLs so the search engine does not treat them as duplicates, and we set up automatic rebuilds when content is updated. This way the team publishes material once, and both versions stay up to date.
After launch, we track the share of pages that pass validation and mobile load time. If a template breaks when a new block is added, it is visible immediately — before the page drops out of fast search results.
What the client receives after AMP implementation
After AMP implementation, the client receives not an "enabled module" but a set of artifacts that allow the system to be developed further and handed over to another team without relying on oral lore. Below is what exactly remains in the repository and in the internal documentation.
- Template configurations. A set of AMP markup templates with build-time validation: separate variants for product cards, articles, categories, and landing pages. Plus rules defining which blocks are allowed and which are stripped automatically — so that a developer doesn't break the markup manually.
- Caching schemes. A map: what is cached on the CDN side, what is cached on the application side, what the time-to-live is for each content type, and how the cache is invalidated on updates. Separately — behavior when the source is unavailable, so that the page doesn't return an empty response.
- Security policies. Configured headers, restrictions on embeddable content, rules for handling external scripts and forms. Everything is documented so that a new developer doesn't disable protection for the sake of a "quick fix."
- Documentation. A description of the project structure, extension points, dependencies, and how to reproduce the build locally. With examples of typical tasks: add a new template, change markup, connect a new data source.
- Update procedures. The order of releasing changes: how markup validity is checked, which checks are mandatory before publication, how a failed release is rolled back, and who is responsible for each point.
- Monitoring and reporting. A dashboard with key metrics: share of valid pages, delivery speed, cache errors. Alerts are configured for deviations from the norm — the problem is visible before a user notices it.
- Handover instructions. A checklist for onboarding a new team: access, environments, deployment order, contacts of responsible persons. Handover takes days, not weeks of back-and-forth.
Each item is a result that can be verified: open the repository, run the build, look at the dashboard. If such artifacts are not present at the end of implementation, then the work is not complete, and we honestly record this at acceptance.
Case study: accelerating mobile delivery for an online store
An online store with a catalog of several thousand items came to us with a typical pain point: mobile delivery was lagging, and analytics showed that visitors were leaving before the product cards finished rendering.
Measurements confirmed the hypothesis — on smartphones in networks with unstable coverage, the category page took too long to assemble, and a significant share of visits ended in a bounce before the first screen even appeared.
What we did
We split the frontend into two circuits. The main site stayed on its familiar stack with full functionality, while for catalog pages and product cards we built lightweight AMP versions: only critical markup, deferred image loading, and no blocking scripts.
Canonical links and structured data markup tied both versions together so that the search engine served the fast variant to mobile users and the full one to desktop users.
We addressed images separately: converted the catalog to modern formats and fixed container dimensions so the layout wouldn't "jump" during loading. We moved static caching to the edge — a repeat visit became noticeably lighter than the first.
Result
| Metric | Before | After |
|---|---|---|
| Mobile load time | 6–7 s | 1.5–2 s |
| Bounce rate on catalog pages | ~58% | ~31% |
| Rankings for commercial queries | outside the top ten | top-5 for key categories |
The project was led by our engineer responsible for the frontend and markup; the work was accepted based on measurements in real conditions, not synthetic tests.
After launch, the share of mobile traffic from fast delivery grew, and the add-to-cart conversion on these pages improved along with the speed.
How does AMP differ from responsive design?
These are two different approaches to the same task — serving a page quickly on any screen. Responsive design is flexible layout: the same markup reflows to fit the screen width via media queries, and the behavior is defined by your own styles and scripts.
AMP is a separate markup format with its own set of tags and strict rules: some familiar elements are replaced with built-in components, third-party code is connected only through allowed blocks, and critical styles are inlined directly into the document.
Hence the main difference — the degree of freedom.
Responsive doesn't restrict you: you build layouts however you like, connect any libraries, analytics, and external widgets, but you're responsible for speed and stability yourself — image optimization, lazy loading, and render order fall on the team.
AMP takes these decisions on itself: the format's rules prevent you from accidentally tanking performance, so the page predictably passes validation and displays quickly on a weak mobile connection.
AMP's limitations are its own guarantee. You can't insert an arbitrary third-party script, a heavy slider, or a custom animation without a ready-made component; some interactivity has to be rebuilt using the available elements.
Responsive sets no such boundaries, but it also doesn't protect against regressions: one heavy library — and loading metrics drop across all pages.
In practice, it's not either-or. Responsive layout remains the foundation of the site, while AMP makes sense as a separate lightweight layer for pages that must open instantly from search and news feeds.
We figure out which pages benefit from the format and which are cheaper to speed up using responsive's own means, and we build both variants so they don't conflict in markup and analytics.
Common technical questions about AMP pages
AMP pages are embedded into an existing site rather than replacing it: the canonical URL remains with the main document, while the lightweight version is served at a separate address and marked with rel="amphtml".
The search engine itself chooses which version to show in mobile results, so it is important that both contain the same content and correct metadata. If canonicalization is set up correctly, AMP does not "steal" traffic but expands entry points.
Maintenance comes down to two regular operations: markup validation and content synchronization.
The validator catches violations of mandatory rules (forbidden tags, inline styles over the limit, third-party scripts), while content desynchronization between versions is the most common cause of ranking drops.
We address this by building from a single source: an edit is made once, and both versions are updated together.
AMP conflicts with our current stack — will we have to rewrite everything?
No. The AMP version is built from the same data and templates as the main site — there is no need to rewrite the logic.
The restrictions apply only to the client layer: third-party scripts are connected through allowed components, and interactivity is implemented with built-in tools.
If some block cannot be ported, it stays on the main site, and in the AMP version it is replaced with a link to the full page.
What happens to SEO if we drop AMP later?
Rolling back is safe: it is enough to remove the rel="amphtml" markup and set up a redirect from the lightweight addresses to the canonical ones.
The search engine will reindex the pages over several crawl cycles, and rankings are preserved because the canonical address has not changed. We keep this procedure in the documentation so that switching in either direction takes hours, not weeks.
How often should validation be checked after updates?
We run validation during the build: if the markup breaks, the release does not go to production. Additionally, once a month we check already published pages — search engine updates sometimes change the requirements for mandatory attributes. This way, violations are found before a page drops out of the search results.
Let's discuss your AMP optimization task
Migrating a site to AMP makes sense not "in general," but for a specific task: speeding up mobile search results, eliminating a drop in bounce rate, pushing a section that is currently underperforming in traffic into the top.
That's why we start the conversation with the inputs — which page templates are the priority, where the traffic is coming from, which metrics you consider your targets.
Then we look at the current markup and decide where AMP will deliver a win and where regular optimization is enough.
The timeline estimate is based on scope: how many page types we're migrating, whether there are dynamic blocks, how the layout and templating engine are structured.
After the review, we provide a phased plan with realistic timelines and a clear understanding of what exactly we check at each step.
What the work includes:
- reviewing current pages and selecting templates for the AMP version;
- designing the AMP markup and its integration with the main version of the site;
- setting up canonical links so the versions don't compete in search results;
- validating the markup and fixing errors before release;
- testing load speed and mobile behavior;
- connecting analytics so you can see the effect in numbers;
- handing over documentation and training your team to work with AMP.
We lock in the result in advance: which pages we're speeding up, by how much we're reducing load time, how we track rankings and bounces after implementation.
Then — support: we monitor markup validity, update templates when the site changes, and investigate any drops if they occur.
Describe your task — which pages you want to speed up and what result you consider successful. We'll come back with a timeline estimate and an implementation plan.
