Official statement
Other statements from this video 8 ▾
- 6:42 Pourquoi la Search Console met-elle autant de temps à refléter les corrections AMP validées ?
- 10:15 L'AMP est-il vraiment limité au contenu statique pour le SEO ?
- 11:48 Faut-il vraiment des données structurées pour apparaître dans le carousel Top Stories en AMP ?
- 20:25 Page canonique, site mobile, AMP : pourquoi Google distingue-t-il ces trois versions ?
- 20:49 L'AMP est-il vraiment inutile pour votre référencement Google ?
- 21:20 L'AMP améliore-t-il vraiment le SEO ou est-ce un mythe ?
- 27:05 L'AMP est-il vraiment adapté aux sites e-commerce ?
- 30:54 AMP dans les résultats Google : pourquoi votre version mobile compte-t-elle plus que vous ne le pensez ?
Google mandates that the CSS of AMP pages be directly embedded in the HTML code, without any external file, with a strict size limit. This constraint aims to eliminate additional HTTP requests that slow down loading. For SEOs, this means rethinking the CSS architecture: everything must fit within the HTML, which necessitates a ruthless culling of style rules and a minimalist design approach.
What you need to understand
What is inline CSS and how does it differ from the conventional approach?
Inline CSS means all your style rules are written directly within the <style> tag of the HTML document, in the <head>. No external .css file is called. Unlike the standard web approach where you link stylesheets via <link rel="stylesheet">, AMP prohibits this practice.
Why? Because each external file generates an additional HTTP request. On mobile, with sometimes unstable connections, these back-and-forth exchanges are costly in terms of time. AMP focuses entirely on raw speed: the HTML arrives with its CSS already embedded, ready to be rendered without waiting.
What is the size limit imposed by AMP?
Google sets a strict limit of 75 KB for all the inline CSS of an AMP page. This figure might seem generous, but it dwindles quickly when adding layout rules, media queries, responsive variants, component styles.
Exceed this limit and your AMP page becomes invalid. It will not be served from Google's AMP cache, which nullifies the main benefit of the format: instant loading speed from mobile SERPs.
How does this constraint impact page design?
This rule forces a brutal trade-off. You must choose which styles are truly worth keeping. Full CSS frameworks like Bootstrap or Tailwind? Forget it. Complex animations? Probably to be minimized. Design variants for 15 different breakpoints? Simplifying is necessary.
Practically, this necessitates a radical mobile-first approach. You build first for the essentials, then add enhancements that fit within the budget. It’s a return to web fundamentals: structure matters more than decor.
- The CSS must be directly integrated into the <style> tag of the <head>
- Strict maximum limit of 75 KB for all styles
- No external CSS files are allowed (zero HTTP requests for styles)
- Requires ruthless optimization: removal of unnecessary rules, minification, simplification of design
- Every KB counts: traditional CSS frameworks are incompatible with this constraint
SEO Expert opinion
Is this restriction in line with modern SEO practices?
Yes, but with a paradox. Google pushes everywhere else to externalize CSS to take advantage of browser caching and reduce HTML weight. Here, it’s the opposite: inflate the HTML to eliminate HTTP requests. This logic holds only if your AMP page is served from the Google AMP cache, which significantly compensates for the initial bloat.
Outside of AMP cache? This approach becomes counterproductive. An HTML of 80 KB with inline CSS loads slower than an HTML of 15 KB + an external CSS of 30 KB in cache. That’s why AMP pages not served from Google’s cache lose their competitive edge.
What nuances should be applied to this rule?
Google says nothing about Gzip compression or Brotli, which drastically reduces the size of repetitive CSS. A file of 75 KB can weigh 15-20 KB once compressed. So the problem isn’t so much network transfer as it is browser-side parsing: 75 KB of CSS to analyze takes up mobile processor time.
Another point: this limit pushes to remove unused styles, which is excellent practice. But be careful with automatic CSS purge tools like PurgeCSS. On dynamic pages or with conditional components, they can remove necessary rules. [To be verified] systematically in a staging environment before production.
In what cases does this constraint become blocking?
On rich editorial sites with varied components: data tables, interactive infographics, comparison modules. Each component brings its styles, and you quickly hit the ceiling. E-commerce sites in AMP also suffer: product sheets with variants, carousels, filters… all consume CSS.
Let’s be honest: many publishers have abandoned AMP precisely because of this rigidity. Core Web Vitals changed the game: we can now achieve equivalent scores without AMP, with a well-optimized external CSS and a good HTTP/2 cache. The question is no longer "Should we use AMP?" but "In what context does AMP still provide measurable advantage?".
Practical impact and recommendations
How do you audit and optimize the CSS of an existing AMP page?
Start by measuring: open your AMP page, inspect the <style> tag, copy all CSS and check its size using a character counter. If you’re flirting with 70-75 KB, you are in the red zone. Next, identify redundant rules: how many media queries for marginal cases? How many styles for components that appear on only 5% of the pages?
Use tools like UnCSS or PurifyCSS to detect unused rules, but validate the results manually. These tools often miss dynamically or conditionally applied styles. A manual pass remains essential on complex sites.
What common mistakes should absolutely be avoided?
A classic mistake: keeping a complete CSS reset like Normalize.css. You load 5-7 KB of rules, 80% of which are useless on your specific page. Create a minimal custom reset, only for the tags you actually use.
Another pitfall: icon fonts like Font Awesome. A complete font can cost 20-30 KB in base64 inline. Prefer inline SVGs for truly necessary icons, or use extremely reduced subsets. Every invisible icon is wasted CSS.
How can you maintain this optimization over time?
Integrate CSS size checking into your CI/CD pipeline. A script that measures the weight of the generated <style> and blocks deployment beyond 70 KB (safety margin). Without this, CSS quietly grows with each feature addition.
Document critical vs. optional style rules. When a developer adds a component, they should immediately know how much CSS budget they consume and what they can remove in return. This editorial discipline is the only guarantee against exceeding the limit.
These optimizations require sharp technical expertise and constant rigor. If your team lacks the time or resources to audit and maintain these constraints, hiring a specialized SEO agency can help you avoid costly mistakes and ensure that your AMP implementation remains performant and compliant over the long term.
- Measure the current size of inline CSS with a character counter or analysis tool
- Remove all unused styles via UnCSS or PurifyCSS, then validate manually
- Replace complete CSS frameworks with minimal custom components
- Convert Font Awesome/similar icons to inline SVG or reduced subsets
- Integrate an automatic CSS weight check in the deployment pipeline (threshold 70 KB max)
- Test each page with the official AMP validator before going live
❓ Frequently Asked Questions
Puis-je utiliser des fichiers CSS externes sur une page AMP ?
Que se passe-t-il si je dépasse la limite de 75 Ko de CSS inline ?
La limite de 75 Ko s'applique-t-elle avant ou après compression Gzip ?
Comment identifier rapidement les styles CSS inutilisés sur mes pages AMP ?
Les frameworks CSS comme Bootstrap ou Tailwind sont-ils compatibles avec AMP ?
🎥 From the same video 8
Other SEO insights extracted from this same Google Search Central video · duration 51 min · published on 15/06/2016
🎥 Watch the full video on YouTube →
💬 Comments (0)
Be the first to comment.