I have implemented lazyload on my images, as instructed by pagespeed insights.
after this, I received a new alert: do not apply lazy load on the LCP element (in this case it is a banner) as it affects the first content paint.
We removed it again and now again I receive a diagnosis to apply lazy load to the LCP images.
I think the tool is not very serious, in my company we work with developers who carry out these tasks and now we have to ask them to go back on this implementation? what is the logic of this?
Related
I am using Application Insights to monitor my APIs. When viewing the performance of my endpoints, AI seems to split requests based on their path, including any path parameters. This is not helpful to me; I would like to investigate performance (and get performance alerts) for e.g. all PATCH /observations/{id} operations when viewed together, not when viewed individually for each {id}.
Put another way, in the screenshot below, I would like the underlined operations to all be in the same row, e.g. PATCH /observations/{id}.
Is this possible without a lot of boilerplate code, and without ruining other monitoring features (which editing the telemetry operation names might, though I may be wrong)?
I am using ASP.NET Core endpoint routing, so the framework has all necessary information about the routing (tokens etc.).
Grouping requests this way for performance monitoring seems so obvious that I am surprised that it is so hard to figure this out, or that there are seemingly no "canonical" and simple way to accomplish this. Please let me know if I am going about this the wrong way.
I got an weird issue. Here is my code for rendering the vue pages. In my local machine, the rendering time for this page is about 50~80ms around, however, if i access the page parallel, sometimes could be 120ms around(maybe 5 times out of 200 requests ), but most of time, it is still 50~80 ms.
However, when i deploy the code to our production docker, these peek time is getting worse, sometimes it can reach 1 second, and got 500ms a lot of times, the performance is bad. It makes no sense, the request load is not heavy and we have load balance too. For a similiar page which we are using EJS to render, we don't see this kind of peek a lot. The backend logic and services using for EJS and Vue are all the same.
Client side rendering is also the same, it has similar symptom.
Does any body know what kind of reasons could lead this issue?
first of all do two things:
1- do a quick test using lighthouse if possible, it'll help pin pointing the problem.
2- check console for any errors AND warnings.
without further information about you'r code i don't think it's possible to say what's exactly causing the problem.
However after searching for some time i came about an article which the writer had the same performance problems.
This is the result of his lighthouse check. As you can see his website had shortcomings in indexing and content full paint; Long story short he had an infinity loop and v-for loops without keys.
following are some tips on how you can better optimize you'r vue app:
Apply the Vue Style Guide and ESLint
There’s a style guide in Vue docs: https://v2.vuejs.org/v2/style-guide/.
You can find there four Rule categories. We really care about three of them:
Essential rules preventing us from errors,
Recommended and strongly recommended rules for keeping best practices – to improve quality and readability of code.
You can use ESLint to take care of those rules for you. You just have to set everything properly in the ESLint configuration file.
Don’t use multiple v-if
Don’t write api call handlers in components
Simply do what is locally necessary in components logic. Every method that could be external should be separated and only called in components e.g. business logic.
Use slots instead of large amounts of props
5.Lazy load routes
Use watcher with the immediate option instead of the created hook and watcher together.
Here another article on how to improve you'r vue app.
Good Luck!
What is the approach for lazy loading images for pages that conform to the Google Accelerated Mobile Pages (AMP) project?
It is my understanding that lazy loading means that the image is loaded to the client sometime after the above-the-fold content is rendered. There appears to be three variants of lazy loading:
view port - image loading is triggered by its proximity to the view port
set delay - image loading is triggered by a timer
manual - image loading is triggered by a client event
All these approaches can be implemented using javascript. However, AMP does not allow for javascript, just custom AMP scripts.
The view port approach is the most desirable, as it minimizes content loading to a minimum. AMP has a custom script that supports the view port approach for starting and stopping videos. However, there does not appear to similar support for amp-img.
The set delay appears to be supported with amp-animation, I think. This seems like a rather complex approach. Further, the delay approach is undesirable as the optimum delay depends on internet bandwidth, which is variable.
The delay approach can also be implemented with PHP. However, PHP is parsed on the server-side. This means that the page would have to reloaded, which entirely defeats the purpose of lazy loading.
It seems that the manual approach is all that remains. The following snippet of code creates two buttons that selectively show or hide an image.
amp-img id='img1' ... hidden
button on="tap.img1.show()"
button on="tap.img1.hide()"
For mobile sites, the show button can be embedded into the above the fold content, so the user triggers it while perusing through the site. However, this seem like a kludge
Does Google AMP effectively limit lazy loading to the manual approach, or is there some other way to accomplish view port or delay lazy loading?
Thank you in advance.
All AMP elements always are always lazy loaded. There is currently no way to configure the thresholds for lazy loading (e.g. based on distance from the viewport).
According to AMP documentation, AMP images are lazy loaded. They state that the <amp-img> tag is used by the AMP runtime to:
understand the layout of the page before assets load, crucial to support first-viewport preloading
control network requests to lazy load and prioritize resources effectively"
So, in short: you don't need to lazy load the images. They already do it for you.
It makes sense for them to do so, especially since the whole point of AMP is performance, and lazy loading is one of the most basic things that can be done to improve speed.
In fact, AMP does something even more clever: prefetching lazy loaded resources:
"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."
If you dig a little deeper into the AMP runtime, you'll see that they actually implement more advanced techniques than just lazy loading, which is why AMP is near instantaneous...
I'm working on a shopping site. We display 40 images in our results. We're looking to reduce the onload time of our page, and since images block the onload event, I'm considering lazy loading them by initially setting img.src="" and then setting them after onload. Note that this is not ajax loading of html fragments. the image html along with the alt text is present. it's just the image src is deferred.
Does anyone have any idea as to whether this may harm SEO or lead to a google penalty box now that they are measuring sitespeed?
Images don't block anything, they are already lazy loaded. The onload event notifies you that all of the content has been downloaded, including images, but that is long after the document is ready.
It might hurt your rank because of the lost keywords and empty src attributes. You'll probably lose more than you gain - you're better off optimizing your page in other ways, including your images. Gzip + fewer requests + proper expires + a fast static server should go a long way. There is also a free CDN that might interest you.
I'm sure google doesn't mean for the whole web to remove their images from source code to gain a few points. And keep in mind that they consider anything under 3s to be good loading times, there's plenty of room to wiggle before resorting to voodoo techniques.
From a pure SEO perspective, you shouldn't be indexing search result pages. You should index your home page and your product detail pages, and have a spiderable method of getting to those pages (category pages, sitemap.xml, etc.)
Here's what Matt Cutts has to say on the topic, in a post from 2007:
In general, we’ve seen that users usually don’t want to see search results (or copies of websites via proxies) in their search results. Proxied copies of websites and search results that don’t add much value already fall under our quality guidelines (e.g. “Don’t create multiple pages, subdomains, or domains with substantially duplicate content.” and “Avoid “doorway” pages created just for search engines, or other “cookie cutter” approaches…”), so Google does take action to reduce the impact of those pages in our index.
http://www.mattcutts.com/blog/search-results-in-search-results/
This isn't to say that you're going to be penalised for indexing the search results, just that Google will place little value on them, so lazy-loading the images (or not) won't have much of an impact.
There are some different ways to approach this question.
Images don't block load. Javascript does; stylesheets do to an extent (it's complicated); images do not. However, they will consume http connections, of which the browser will only fire off 2 per domain at a time.
So, what you can do that should be worry-free and the "Right Thing" is to do a poor man's CDN and just drop them on www1, www2, www3, etc on your own site and servers. There are a number of ways to do that without much difficulty.
On the other hand: no, it shouldn't affect your SEO. I don't think Google even bothers to load images, actually.
We display 40 images in our results.
first question, is this page even a landing page? is it targeted for a specific keyword? internal search result pages are not automatically landing pages. if they are not a landingpage, then do whatever you want with them (and make sure they do not get indexed by google).
if they are a landingpages (a page targeted for a specific keyword) the performance of the site is indeed important, for the conversion rate of these pages and indirectly (and to a smaller extend also directly) also for google. so a kind of lazy load logic for pages with a lot of images is a good idea.
i would go for:
load the first two (product?) images in an SEO optimized way (as normal HTML, with a targeted alt text and a targeted filename). for the rest of the images make a lazy load logic. but not just setting the src= to blank, but insert the whole img tag onload (or onscroll, or whatever) into your code.
having a lot of broken img tags in the HTML for non javacript users (i.e.: google, old mobile devices, textviewer) is not a good idea (you will not get a penalty as long as the lazy loaded images are not missleading) but shitty markup is never a good idea.
for general SEO question please visit https://webmasters.stackexchange.com/ (stack overflow is more for programing related questions)
I have to disagree with Alex. Google recently updated its algorithm to account for page load time. According to the official Google blog
...today we're including a new signal in our search ranking algorithms: site speed. Site speed reflects how quickly a website responds to web requests.
However, it is important to keep in mind that the most important aspect of SEO is original, quality content.
http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html
I have been added lazyload to my site (http://www.amphorashoes.ro) and i have better pagerank from google (maybe because the content is loading faster) :)
first,don't use src="",it may hunt your page,make a small loading image instead it.
second,I think it won't affect SEO, actually we always use alt="imgDesc.." to describe this image, and spider may catch this alt but not analyse this image what id really be.
I found this tweet regarding Google's SEO
There are various ways to lazy-load images, it's certainly worth
thinking about how the markup could work for image search indexing
(some work fine, others don't). We're looking into making some clearer
recommendations too.
12:24 AM - 28 Feb 2018
John Mueller - Senior Webmaster Trends Analyst
From what I understand, it looks like it depends on how you implement your lazy loading. And Google is yet to recommend an approach that would be SEO friendly.
Theoretically, Google should be running the scripts on websites so it should be OK to lazy load. However, I can't find a source(from Google) that confirms this.
So it looks like crawling lazy loaded or deferred images may not be full proof yet. Here's an article I wrote about lazy loading image deferring and seo that talks about it in detail.
Here's working library that I authored which focuses on lazy loading or deferring images in an SEO friendly way .
What it basically does is cancel the image loading when DOM is ready and continue loading the images after window load event.
...
<div>My last DOM element</div>
<script>
(function() {
// remove the all sources!
})();
window.addEventListener("load", function() {
// return all the sources!
}, false);
</script>
</body>
You can cancel loading of an image by removing it's src value or replacing it with a placeholder image. You can test this approach with Google Fetch
You have to make sure that you have the correct src until DOM is ready so to be sure that Google Fetch will capture your imgs original src.
I was making a website for a music band, and i was wondering the best way to play background music on the website without interrupting the flow of the music (even for a split second).
At the moment, i am considering using frames, but this is not supposed to be good practice. Please someone tell me how i can do this. I would prefer to use HTML to code the website as i have not yet mastered coding in flash.
This might sound controversial, but here's an idea: Don't play music on your website. Seriously, don't. I think everyone knows how incredibly annoying that is, and asking a group of software developers to help you out with that is going to be like asking a group of sheep the best way to make a lambskin coat.
If you really have to do it, frames would be the simplest way, so I'd do that. But you're not going to do it anyway, right?
I can think of four ways:
Frames, as you said.
Make your entire website in Flash and have only one page. You need to know Flash to be able to do this, which could make this difficult.
Pop-out your music player. This is probably the easiest approach, but the downside is this could be annoying, and a lot of web browsers these days would block it.
Use AJAX and dynamically load all your site content within one page, like Gmail. Users will need to have newer browsers, and this will take quite a bit of coding on both the client and the server side.
The only way to prevent the music from stopping is to not let the page your music component is on reload. Currently the only way to do this is to use frames, unfortunately.
The only alternative is to develop the whole site in Flash or another technology that doesn't rely on changing pages as navigation.
It wouldn't be pretty but you could do it using AJAX. Have the master page with the header/footer/navigation controls with a big empty content div, and instead of regular links you have calls to AJAX functions that return HTML to be injected in the content div.
I tend to agree with the others who recommend frames. It may be considered "bad practice", but so is playing background music in the first place.
As was said, to do that you have to prevent your website from relaoding.
An option to achieve this might be to use asynchronous requests to modify your website content without reloading the whole page, that's basically what Ajax is about.
That being said, I sort of agree with Alex here : dont' play music.
This may be a topic for another post, but why would you cosnider IFrames to be good practice? you could out the content you want to change into an IFrame and have your code running your music player ouside it. When you load a page it woul load on the IFrame. Just a thought...
You would most likely need flash or a new window (pop-up) outside of the window.
Don't use frames. Ever.
EDIT: To all the people downmodding and commenting on this, not a single person has given a valid reason why you SHOULD use frames.
Just to clarify my position, please read ANY article on usability, the web, and frames.
For those still learning (and to those old people to dumb to update)
Frames break the unified model of the web.
Frames cause problems for search engine robots.
Frames make URLs stop working.
Frames break bookmarking.
Frames make printing more difficult.
Frames hurt accessibility.
Frames increase technical complexity.
and the #1 reason to not use frames......
USERS HATE THEM!
http://www.456bereastreet.com/archive/200411/who_framed_the_web_frames_and_usability/
Are there seriously this many people out there suggesting frames are a valid solution in 2009? How disappointing.