Twitter Bootstrap is very well known CSS framework today . It is easy to Use CSS framework that helps in Creating Responsive Web pages . I am going to give a Brief Overview of How Bootstrap Differentiate between Different Screen Sizes
Bootstrap includes a responsive, mobile first fluid grid system that appropriately scales up to 12 columns as the device or viewport size increases. It includes predefined classes for easy layout options, as well as powerful mixins for generating more semantic layouts.
Media queries
Bootstrap Uses Media Queries To Differentiate Between Screen Sizes . See Below What is code behind these media queries
/*================================================== = Bootstrap 3 Media Queries = ==================================================*/ /*========== Mobile First Method ==========*/ /* Custom, iPhone Retina */ @media only screen and (min-width : 320px){ } /* Extra Small Devices, Phones */ @media only screen and (min-width : 480px){ } /* Small Devices, Tablets */ @media only screen and (min-width : 768px){ } /* Medium Devices, Desktops */ @media only screen and (min-width : 992px){ } /* Large Devices, Wide Screens */ @media only screen and (min-width : 1200px){ } /*========== Non-Mobile First Method ==========*/ /* Large Devices, Wide Screens */ @media only screen and (max-width : 1200px){ } /* Medium Devices, Desktops */ @media only screen and (max-width : 992px){ } /* Small Devices, Tablets */ @media only screen and (max-width : 768px){ } /* Extra Small Devices, Phones */ @media only screen and (max-width : 480px){ } /* Custom, iPhone Retina */ @media only screen and (max-width : 320px){ }
The following optimizations combined are the reason AMP pages are so fast they appear to load instantly: Allow only asynchronous scripts
JavaScript is powerful, it can modify just about every aspect of the page, but it can also block DOM construction and delay page rendering (see also Adding interactivity with JavaScript). To keep JavaScript from delaying page rendering, AMP allows only asynchronous JavaScript.
AMP pages can’t include any author-written JavaScript. Instead of using JavaScript, interactive page features are handled in custom AMP elements. The custom AMP elements may have JavaScript under the hood, but they’re carefully designed to make sure they don’t cause performance degradation.
While third-party JS is allowed in iframes, it cannot block rendering. For example, if third-party JS uses the super-bad-for-performance document.write API, it does not block rendering the main page.
Size all resources statically
External resources such as images, ads or iframes must state their size in the HTML so that AMP can determine each element’s size and position before resources are downloaded. AMP loads the layout of the page without waiting for any resources to download.
AMP uncouples document layout from resource layout. Only one HTTP request is needed to layout the entire doc (+fonts). Since AMP is optimized to avoid expensive style recalculations and layouts in the browser, there won’t be any re-layout when resources load.
Don’t let extension mechanisms block rendering
AMP doesn’t let extension mechanisms block page rendering. AMP supports extensions for things like lightboxes, instagram embeds, tweets, etc. While these require additional HTTP requests, those requests do not block page layout and rendering.
Any page that uses a custom script must tell the AMP system that it will eventually have a custom tag. For example, the amp-iframe script tells the system that there will be an amp-iframe tag. AMP creates the iframe box before it even knows what it will include:
Keep all third-party JavaScript out of the critical path
Third-party JS likes to use synchronous JS loading. They also like to document.write more sync scripts. For example, if you have five ads on your page, and each of them cause three synchronous loads, each with a 1 second latency connection, you’re in 18 seconds of load time just for JS loading.
AMP pages allow third-party JavaScript but only in sandboxed iframes. By restricting them to iframes, they can’t block the execution of the main page. Even if they trigger multiple style re-calculations, their tiny iframes have very little DOM.
The time it takes to do style-recalculations and layouts are restricted by DOM size, so the iframe recalculations are very fast compared to a recalculating styles and layout for the page.
All CSS must be inline and size-bound
CSS blocks all rendering, it blocks page load, and it tends to get bloated. In AMP HTML pages, only inline styles are allowed. This removes 1 or often more HTTP requests from the critical rendering path compared to most web pages.
Also, the inline style sheet has a maximum size of 50 kilobytes. While this size is big enough for very sophisticated pages, it still requires the page author to practice good CSS hygiene.
Font triggering must be efficient
Web fonts are super large, so web font optimization is crucial to performance. On a typical page that has a few sync scripts and a few external style sheets, the browser waits and waits to start downloading these huge fonts until all this happens.
The AMP system declares zero HTTP requests until fonts start downloading. This is only possible because all JS in AMP has the async attribute and only inline style sheets are allowed; there’s no HTTP requests blocking the browser from downloading fonts.
Minimize style recalculations
Each time you measure something, it triggers style recalculations which are expensive because the browser has to layout the entire page. In AMP pages, all DOM reads happen first before all the writes. This ensures there’s the max of one recalc of styles per frame.
Learn more about impact of style and layout recalculations on rendering performance.
Only run GPU-accelerated animations
The only way to have fast optimizations is to run them on the GPU. GPU knows about layers, it knows how to perform some things on these layers, it can move them, it can fade them, but it can’t update the page layout; it will hand that task over to the browser, and that’s not good.
The rules for animation-related CSS ensure that animations can be GPU-accelerated. Specifically, AMP only allows animating and transitioning on transform and opacity so that page layout isn’t required. Learn more about using transform and opacity for animation changes.
Prioritize resource loading
AMP controls all resource downloads: it prioritizes resource loading, loading only what’s needed, and prefetches lazy-loaded resources.
When AMP downloads resources, it optimizes downloads so that the currently most important resources are downloaded first. Images and ads are only downloaded if they are likely to be seen by the user, above the fold, or if the user is likely to quickly scroll to them.
AMP also prefetches lazy-loaded resources. Resources are loaded as late as possible, but prefetched as early as possible. That way things load very fast but CPU is only used when resources are actually shown to users.
Load pages in an instant
The new preconnect API is used heavily to ensure HTTP requests are as fast as possible when they are made. With this, a page can be rendered before the user explicitly states they’d like to navigate to it; the page might already be available by the time the user actually selects it, leading to instant loading.
While prerendering can be applied to all web content, it can also use up a lot of bandwidth and CPU. AMP is optimized to reduce both of these factors. Prerendering only downloads resources above the fold and prerendering doesn’t render things that might be expensive in terms of CPU.
When AMP documents get prerendered for instant loading, only resources above the fold are actually downloaded. When AMP documents get prerendered for instant loading, resources that might use a lot of CPU (like third-party iframes) do not get downloaded.
AMP HTML is a way to build web pages for static content that render with reliable, fast performance. It is our attempt at fixing what many perceive as painfully slow page load times – especially when reading content on the mobile web.
AMP HTML is entirely built on existing web technologies. It achieves reliable performance by restricting some parts of HTML, CSS and JavaScript. These restrictions are enforced with a validator that ships with AMP HTML. To make up for those limitations AMP HTML defines a set of custom elements for rich content beyond basic HTML. Learn more about how AMP speeds up performance.
How does AMP HTML work?
AMP HTML works by including the AMP JS library and adding a bit of boilerplate to a web page, so that it meets the AMP HTML Specification. The simplest AMP HTML file looks like this:
The AMP JS library provides builtin AMP Components, manages the loading of external resources, and ensures a reliably fast time-to-paint.
The AMP Validator
The AMP Validator allows a web developer to easily identify if the web page doesn't meet the AMP HTML specification.
Adding "#development=1" to the URL of the page instructs the AMP Runtime to run a series of assertions confirming the page's markup meets the AMP HTML Specification. Validation errors are logged to the browser's console when the page is rendered, allowing web developers to easily see how complex changes in web code might impact performance and user experience.
It also allows apps that integrate web content to validate the web page against the specification. This allows an app to make sure the page is fast and mobile-friendly, as pages adhering to the AMP HTML specification are reliably fast.
AMP HTML Components are a series of extended custom elements that supplement or replace functionality of core HTML5 elements to allow the runtime to ensure it is solely responsible for loading external assets and to provide for shared best practices in implementation.
We push a new release of AMP to all AMP pages every week on Thursday. The more detailed schedule is as follows:
Every Thursday we cut a green release from our master branch.
This is then pushed to users of AMP who opted into the AMP Dev Channel.
On Monday we check error rates for opt-in users and bug reports and if everything looks fine, we push this new release to 1% of AMP pages.
We then continue to monitor error rates and bug reports throughout the week.
On Thursday the "Dev Channel" release from last Thursday is then pushed to all users.
You can always follow the current release state of AMP on our releases page. The release used by most users is marked asLatest release and the current Dev Channel release is marked as Pre-release.
AMP Dev Channel
AMP Dev Channel is a way to opt a browser into using a newer version of the AMP JS libraries.
This release may be less stable and it may contain features not available to all users. Opt into this option if you'd like to help test new versions of AMP, report bugs or build documents that require a new feature that is not yet available to everyone.
Opting into Dev Channel is great to:
test and play with new features not yet available to all users.
use in Q&A to ensure that your site is compatible with the next version of AMP.
If you find an issue that appears to only occur in the Dev Channel version of AMP, please file an issue with a description of the problem. Please always include a URL to a page that reproduces the issue.
To opt your browser into the AMP Dev Channel, go to the AMP experiments page and activate the "AMP Dev Channel" experiment. Please subscribe to our low-volume announcements mailing list to get notified about important/breaking changes about AMP.
Further Reading
If you are creating AMP pages, check out the docs on ampproject.org.
These docs are public and open-source: https://github.com/ampproject/docs/. See something that's missing from the docs, or that could be worded better? Create an issue and we will do our best to respond quickly.
