PageSpeed calibration problem with Google AMP [amp-img]? - pagespeed-insights

Google PageSpeed penalty "Defer offscreen images" since adopting Google AMP (amp-img). It seems that PageSpeed encourages AMP to load ALL images! Prior to AMP I used JS to LazyLoad images located beyond the initial viewport. I'm open to suggestions on how to retain AMP but avoid the PageSpeed penalty.
Example: (the code for this image sits below the initial viewport, near the bottom of the page)
::: Top area of page - initial viewport area :::
… "The fold"
off-page, below fold, near bottom page on 2nd page of viewport
When rated on PageSpeed, despite this image being off-page the AMP runtime does not defer load and results in a penalty score!
(Code removed since the StackOverflow editor refused to allow it!)
Since AMP prohibits my old JS LazyLoad technique, I am at the mercy of this stated AMP behaviour: "The runtime may choose to delay or prioritize resource loading based on the viewport position, system resources, connection bandwidth, or other factors." (https://amp.dev/documentation/components/amp-img?format=websites)
So it seems that by adopting AMP I have relinquished control over lazy load to Google AMP's runtime, which "may" choose to delay. When PageSpeed rates an AMP page, you'd think AMP runtime would want to impress, right? You'd think AMP runtime WOULD "choose to delay" (amp-img) content appearing off-page (not within the initial viewport area). You'd be wrong.
The PageSpeed penalty message is as follows:
"Defer offscreen images.
Consider lazy-loading offscreen and hidden images after all critical resources have finished loading to lower time to interactive"
I love AMP, but is there an opportunity for the guys at PageSpeed to collaborate with the guys over at AMP? I agree with PageSpeeds description of this situation, calling it an "Opportunity". Sadly when I adopted AMP I seem to have handed over this "opportunity" to AMP runtime...and am penalized for doing so.
Can anyone provide a pragmatic workaround, so that I can retain AMP but not get penalized on PageSpeed when using (amp-img) for images positioned beyond the initial viewport?

Related

Texture Shows Flickering / Aliasing / Moire Patterns in Godot, Despite Mipmaps

If I load a checkerboard texture into Godot:
And stand far enough back from it, I get strange artifacts called Moiré patterns:
This is a well-known problem in computer graphics which appears whenever you sample a texture that has a higher resolution than the area of the screen it is being rendered onto. (See this article for another illustration and full explanation.)
The usage of mipmaps is a technique to eliminate this problem by making lower-resolution versions of the texture that are then used when the camera is sufficiently far away from the object. So, I went to find out how to enable this in Godot only to find out that it was already enabled by default:
Why then am I still getting aliasing? What can I do to eliminate it?
By default, Godot selects a higher resolution mipmap than what is needed to completely eliminate aliasing. At the cost of making your materials blurrier, the aliasing can be almost entirely removed by increasing the "Texture Mipmap Bias" by one. What this does is tell Godot's rendering engine to pick the mipmap that is half the resolution of the one it would normally pick. The setting can be found as follows:
Go to Project > Project Settings....
Enable "Advanced Settings" to the right of the search bar.
Navigate to Rendering > Textures on the left.
The setting can then be found in Default Filters > Texture Mipmap Bias on the right.
The result:

How to set the default resolution in windows 8.1 winjs app

I'm working on my first winjs app for windows 8.1. So I'm a newbie in this topic, so please forgive me if I ask something obvious.
My problem is the resolution of the target machine (DELL Latitude E7440 with touch screen) is 1920x1080, but when I run the app, it runs in 1370x771. Which is a bit confusing for me.
So my question is, how can I tell the app to run in the same resolution as the OS runs.
Strange thing I discovered: If I set the "Change the size of apps text, and other items on the screen (...)" settings from larger to default in the display settings then suddenly my app runs in the desired full hd resolution. But I don't wanna depend on this setting.
I know I could use ViewBox control, but all of the graphics and everything is designed for full hd resolution, so ViewBox would simply scale it down, this solution sounds a bit ridiculous considering I have a full hd laptop, and full hd design as well...
This app is only for this particular machine, so I don't have to deal with different resolutions.
Any tip/suggestion is highly appreciated.
Windows abstracts the physical device resolution specifically so you don't have to think about scaling issues. Just do your work against the resolution that's reported from the API. This is done because a high pixel density display can result in UI that's too small to be usable, e.g. touch targets that get too small for fingers. Most of the time, then, a 1920x1080 display that's on a smaller physical device (e.g. 13" or smaller screens) gets a 140% scaling factor applied, hence it reports something closer to 1366x768.
Generally speaking, then, if you write responsive CSS for layout then you really don't need to worry about scaling at all with the exception of providing raster graphics that can work at the 100%, 140%, and 180% scaling plateaus (and 240% on Windows Phone 8.1).
For more details refer to my free ebook from Microsoft Press, Programming Windows Store Apps with HTML, CSS, and JavaScript, 2nd Edition, which you can also read (free) within the Microsoft Press Guided Tour app in the Store. Page 42 (Chapter 1) has a short overview on Views and Resolution Scaling; the Branding Your App section on page 113 talks about sizes of logo/splashscreen images for different resolutions, and then Chapter 8, "Layout and Views" (starting on page 421) goes into all the details, especially "Screen Resolution, Pixel Density, and Scaling" on page 437.

How big is too big when coming to background images?

I am having a little issue here. I am a web development major and I am currently building this site for a project I am required to do. I wanted to make it look pretty with a background image. I created the image in Photoshop and saved it to web as a .jpg and it ended up being 58.8k in size.
I am all for websites that load quick for the user, but I am wondering if less than 60k is okay? I checked it on the yslow firefox extension and it loads for me in 96 ms (slightly poor test subject - http://www.speedtest.net/result/1146275377.png)
Is 60k too much, is it a best practice to have images only 10-20k? I HATE it when I see an image loading... it just.. isn't even worth the graphic at that point. Is there quicker ways to load a image of that size? CSS or tag? Or should I not even be worrying about it?
Most browsers load the background image last by default, so you shouldn't have a problem.
How large is too large depends on your hosting set up, the amount of traffic your site gets, and the typical transfer rate of your visitors.
60k seems reasonable to me for an average site with not too many simultaneous visitors. However, bandwidth costs money and this is the reason that you rarely see background images of that size on big sites. On the other hand, youtube regularly streams videos that are thousands of times larger than the background image that you propose. It's impossible to give you precise advice without knowing much more about your site, its hosting solution and it's usage statistics.
Chances are, if you're asking this question, 60k is perfectly fine.
If you want to guarantee that your background image loads first or last you can do:
<script type="text/javascript">
bgimage = new Image();
bgimage.src = "http://www.olhovsky.com/img/cdf97/256fwt1_eg.png";
</script>
Place that code above the body tag to preload the background image. Place it lower in your html document to load it later (e.g. after the </body> tag to load the background last).
And then in the body tag:
<body onload="document.body.background=bgimage.src;">
I don't think 60k is too large although you probably want to look at your likely users and think about what their connection speeds will be like. If you wanted to try and squeeze the file size down as much as possible, try smushing it as well and you might see it drop a little further.

What is the average resolution i.e pixel width for a standard web page?

I just finished constructing web pages and am trying to decide what the optimal lay out should look like. I am trying to decide between a fixed width for my main divs (about 1200 pixles or so) and a variable percentage width. I worry that the variable width will look awful under lower resolutions of under 1600 by 900. I am assuming < 1600 X 900 resolution is pretty rare out there these days but would love some opinions.
Quazi
Re replies:
Thank you all for your valuable remarks. It turns out my problems stemmed from using a mixture of variable divs with fixed width elements. A total disaster for viewing at lower resolutions. Your comments led me in the right direction. thank you
Google has a Browser Size page which shows statistics for the browser window size of people who visit Google. You can overlay any website over the graph to see what would be visible on various browser sizes.
So while this is a different statistic from overall screen resolution, it shows that many people view the web using small browser windows - e.g. 30% have a window smaller than 1000 x 575 or so.
Note - the statistics are apparently about a year old.
I first saw this tool mentioned in this answer to a question on the Pro WebMasters SE.
I assume the average resolution for a web page is really just the average resolution for a monitor. I find fixed-width layouts kind of annoying when I go to sites that are only using a fraction of my screen, but I understand why some people do it. Getting it right on a wide range of screens can be a real pain.
If you want to make sure it looks good on all screen sizes, you can use different stylesheets for different resolutions. Or you can alter the layout using javascript as sites like amazon do.
Be better to use percentage size on CSS.It good for every platform.

What's the standard "minimum" resolution I should support with a website? [duplicate]

This question already has answers here:
Closed 13 years ago.
Duplicate:
Recommended website resolution (width and height)?
I tend to think of 1024x768 as the minimum Screen Resolution that a modern web browser will run in, but I worry when using this resolution for a business website because I feel that I might be hurting the folks out there who are stuck with something smaller/older. So I ask, realistically, what is the minimum screen resolution I should expect my website to function perfectly in with the browser "maximized"?
Look to the Netbooks for a new minimum. I'd say 1024x600 is reasonable.
Edit: You can always look to any number of sites that give you statistics on browser usage. Here's one that Google turned up for me:
http://www.w3schools.com/browsers/browsers_display.asp
From an article in Jacob's Nielsen Alertbox called Screen Resolution and Page Layout:
Optimize Web pages for 1024x768, but
use a liquid layout that stretches
well for any resolution, from 800x600
to 1280x1024.
Depends on your audience. If it's mainly American consumers at home, then I think you're safe with 1024x768. For schools, corporate and global international audiences you'll want 800x600 because schools and businesses are less likely to have upgraded computers, and international audiences in various countries may not have larger screens available for whatever reason.
Can I also suggest you test a maximum resolution as well. Many sites are unusable (without zooming) at 1920x1200 due to people using fixed font sizes and the like.
Dear God, have we forgotten?
The WHOLE POINT of HTML - a LOGICAL page description language - is that you NEVER have to think or worry about the display device.
What happens if the display device is a text-reader for the blind?
Or a text-only browser on a console?
But that's not the main point; the main point is that HTML LOGICALLY describes the page. If you in your logical description of the page are making PURELY PHYSICAL descriptions then you GOT IT WRONG. You're writing web-pages like you're Word emitting HTML!
You need to write your web-site so it works LOGICALLY - which is to say, you leave the problem of rendering PURELY in the hands of the rendering agent. If you're not doing that, you've got it WRONG.
Consider using a fluid layout that adapts to the user's screen. Most sites with a fixed layout force the majority of users to view the site targeted to the least common denominator even though 90% of the visitors have a much higher resolution available. This results in layouts that are overly populated with navigational chrome and little content.
If you must use a fixed layout, consider taking a cue from MSN where you split the screen into 760 and 224 pixel columns. If the visitor has a resolution of 800 (which you can detect in JavaScript) then hide the 224 pixel column.
UPDATE from comments: As for determining a safe min though I'd set your screen to 800x600 then browse some of the popular general public sites - MSN, Yahoo, etc. and see what they do. It's a good bet they've invested a lot of research in this area and adopting what they've done is usually a safe bet
1024x768 is fine. Most people have that resolution setting and the ones who don't won't have a heavily compromised user experience. Also, to ensure your page fits nicely into the browser, taking into account scroll-bars and such, make the with of your pages 960px.
1) My browser is not maximized. The size of my screen doesn't matter. The size of my browser window does.
2) The iPhone's screen resolution is 480x320. NewEgg currently lists at least one 1920x1080 monitor for under $200. Designing to either of those resolutions will make your site completely unusable on the other. Even if you split the difference and design to 1024x768, you'll get a stripe covering half the screen width on the $200 monitor (which, IMO, looks like crap) and it will still be completely unusable on the iPhone.
Screens aren't just getting bigger. They're also getting smaller. The trend is moving to fluid layout instead of fixed-width and it's for a damn good reason.
I usually design websites 800 wide.
Height isn't a problem, as the user can scroll.
As Mark said, there are a number of netbooks around now.
Most of them now have the 1024x600 size, but there are also some of the "older" netbooks that have lower resolution then that still. Mine for example has *wince* 800x480.
If you want to be really compatible, go for 800, but otherwise, I'd say your good with 1024, and as for the height, the user can always scroll.
Don't forget that scrollbars, toolbars, and sidebars can constrict the space a little. Even if you assume the resolution is at least 1024*768, don't make your page 1024 wide.
Definitely 1024 wide (as in 980px or so usable), but please don't design for a fixed height.
I'd take a look at those statistics: http://www.w3schools.com/browsers/browsers_display.asp.
As of January 2009, only 4% of people visiting W3Schools are using 800x600 as resolution. The remaining, are using at least 1024x768.
Beware of how much of that 4% could be part of you users, though.

Resources