Speed tests report that my site loads in about 8 seconds on mobile and 2 on desktop.
When looking at the "waterfall" of the asset/script loading it seems to be mostly due to 3rd party analytic scripts like zendesk, hubspot, and google analytics.
Is there anyway to optimize a site for mobile when using these type of scripts?
As far as the files go on my site I've optimized them nearly as much as I could. I've even used a cron (probably not a great idea) to cache the google analytics script locally and fetch a newer version every few days.
I've looked into using Tag Manager or something like Segment to optimize the script loading of these files, but I'm not sure if that will actually improve performance or if those services are mostly just for convenience.
I've also looked at service workers for mobile app caching, but I'm not sure if that will help either and don't want to dive into learning how to use them if it won't actually make a difference.
To sum up, is there a way to speed up mobile with multiple 3rd party analytic scripts or am I just going to have to forgo using some of them or possibly add a mobile version or AMP version without using them or some of them.
Since you've tagged AMP in your question, I'll answer from the AMP perspective:
AMP solves this problem by using a mediator that connects directly to the endpoints of various analytics providers, replacing their clunky and power hungry JS scripts.
Of course, AMP comes with its own set of constrains and is really only targeted at powering static content, but if you're willing to go that route, learn more about AMP Analytics here.
Related
I (or a lot of German people) need your help.
In Germany, more and more website operators are receiving a legal letter with a warning and are supposed to pay around €170. The problem is that it doesn't stop there, which means that if you pay the €170, someone else can come right away and warn you again.
It's about Google Fonts. Many Wordpress websites use themes that load Google Fonts. The German court has decided that it is not allowed to send the IP address to the Google because of Google Fonts and this is a violation of the rights of the customers.
Since I run a few websites, I'm now looking for a solution, but to be honest I'm coming up against technical limits. So I want to open this thread to discuss possibilities.
I have listed issues below, I will add them to my solutions.
I can think of the following options:
Create a child theme and then load the Google fonts locally. (Issue: 1st 2nd 3rd 4th)
Service worker that rewrites the URLs
(Issue: 5.)
Nginx rewrite, rewrite the php output and replace google fonts url
(Issuing: 1. 4.)
More?
Issues:
If you have e.g. integrated a script (Google Maps, Recaptcha, Intercom, ...) it can happen that Google Fonts are reloaded by Javascript.
Theme updates.
A lot of work when multiple customers.
Plugins load elements on certain pages or only later after it can happen that google fonts are loaded again.
Only works if the service worker is installed
I am open for any idea. It looks like Google will not fix this.
There is no easy technical fix. The only long-term fix is to review how you include any third-party content on your websites, in case this embedding causes any visitor personal data to flow to such third parties.
This is not a new development. A lot of the relevant compliance steps already entered the (German) mainstream in the early 2010s when the problem was Facebook's “Like button”. The generally accepted solution for that is that the third party content is not loaded directly. Instead, a placeholder widget is rendered that indicates which content would be available there. Then, the user can give consent with one click and the actual embedded content is loaded.
With Google Fonts, no such consent flow is needed or appropriate. All of the fonts on Google Fonts are Open Source licensed – you are allowed to use and distribute them for free, but subject to the license conditions (like making the license notice available to users). So on a technical level, it is easy to self-host the fonts in question.
What is tricky is efficiently rewriting the requests caused by your websites to point to your own servers instead of to the Google servers. You have identified a couple of approaches and have identified their pros and cons. Some comments:
Client-side rewriting sounds very fragile, I'd avoid it.
Server-side rewriting can be very powerful, but would also be somewhat fragile. The main advantage of such rewrites would be that it doesn't just handle Google Fonts embeds from your themes, but also requests inserted by server-side plugins.
Updating the theme is the only reliable long-term solution. Creating a child theme might be a suitable stop-gap measure until the theme developer fixes the problem. Similarly, it may be necessary to temporarily modify WordPress plugins.
I think that as a band-aid, server-side rewrites will be good enough to prevent many automated scanning tools used by these cease-and-desist lawyers from sounding the alarm on your sites.
However, you have correctly identified that especially JavaScript could cause problems for achieving actual compliance. This is why you should revisit your decisions about what plugins and scripts you have integrated. Loading third party JavaScript has pretty much the same legal consequences as loading fonts from Google, so you should only do it if it's actually necessary for your site (where necessity depends on the user's perspective), or if the user has given valid consent. For example, you can use the placeholder widget technique mentioned above for embedded content like Google Maps or Intercom, whereas loading a Captcha may indeed be strictly necessary on some pages.
For testing these issues, I'd recommend installing Firefox with the uBlock Origin addon, and setting the addon to hard mode. This will block all third-party/cross-origin requests. You can then allowlist those domains that are under your direct control, or are provided by your data processors (who are contractually bound to only use the personal data as instructed by you, and are considered first-party for GDPR purposes), or domains for which you have a legal basis to share the data (e.g. a “legitimate interest” to load stuff that is strictly necessary for your site to work, or to investigate what requests are made when the user gives consent).
IANAL but the two sections may be relevant.
Using their APIs. From what I can tell nothing here explicitly forbids proxying.
API Prohibitions on sublicensing. The last part of the statement and offer it for use by third parties means you're okay as long as you're not offering it for other people to use.
I do have Google Fonts Proxy Docker Image which I use for my own stacks, I don't offer the use of my running proxy for use with other services. It does not mean you can't simply deploy my image on your own servers.
This won't resolve your 3rd party Google services such as Maps though.
I have seen a lot about offloading large scripts from the main thread to help improve website performance and Google's Core Web Vitals. I am curious if there is a way to use web workers to load a third-party script, like Google Analytics or the Facebook pixel (or really any third party script), so that these processes don't bog down the main thread.
If it is possible, could this also be done, in theory, for external CSS stylesheets or CSS libraries?
Since this answer appears on the first page when googling on how to offload 3rd party scripts to Web Worker I thought it would be nice to update:
There is a library called Partytown which does exactly this and much more
I am curious if there is a way to use web workers to load a third-party script, like Google Analytics or the Facebook pixel (or really any third party script), so that these processes don't bog down the main thread.
No. Those scripts are designed to interact with the DOM (which isn't available inside a worker). They aren't CPU intensive anyway so you wouldn't see any performance benefits.
If it is possible, could this also be done, in theory, for external CSS stylesheets or CSS libraries?
No. Workers run JS not CSS (and again, CSS interacts with the DOM).
We are using in house tracking mechanism for our website. We use our tracking.js file on our all pages.
Every page sent some info in an js object to this script file which later send this information to our tracking application using spring controller.
Now as to move page faster we use some pages in AMP templates.
But this does not allow us to use tracking.js
We tried iframe tag but it does not allow to use http call (it only allow https calls)
Could you please suggest a way to do it as it very critical and we can not move to https right now for other limitation.
Thanks
Virendra Agarwal
You can't use tracking.js with AMP as it is considered as an external library. It's written on their How It Works page that it won't allow author-written/3rd party JS:
"One thing we realized early on is that many performance issues are
caused by the integration of multiple JavaScript libraries, tools,
embeds, etc. into a page. This isn’t saying that JavaScript
immediately leads to bad performance, but once arbitrary JavaScript is
in play, most bets are off because anything could happen at any time
and it is hard to make any type of performance guarantee. With this in
mind we made the tough decision that AMP HTML documents would not
include any author-written JavaScript, nor any third-party scripts."
Only the components on this AMP example can be used.
As we worked with Google. We got it sorted.
You can add your API to AMP pages after validation by Google.
This API must be behind https and all calls should be validated by Google.
Google then will white list on AMP page and you can use that code in production.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I am at the final stages of my website, and currently I need to find a suitable statistics application/tool.
I have looked into webalizer, but it seems outdated.
Also, I have looked into Google analytics, but I am afraid that if I implement it, my website will go slow. It is already pretty heavy with database material being displayed which is dynamic btw.
I have read I can put the GA js code at the bottom of the page and thus the page will load first, but I still don't want a slow down.
You are all much more experienced in statistics than I am, so I believe you can give me some good advice.
I have my own private server (Linux) and I have root access as well (offcourse).
Do you think I should have a statistics app on the server, without interferring with my website, or should I go the Google way and use analytics?
Please give me good application names which you have tested etc...
Thanks
Any additional calls to scripts will slow down your site. However, Google Analytics instructs you to place it in a specific place so that it isn't loaded until the page has loaded. (It used to be before the </body> tag but I believe it's now supposed to be the last <script> in the <head> tag.) Don't worry about it too much; the benefits of analytics will far outweigh the extra call to a remote file.
Focus on other optimizations (database queries, CSS sprites, fewer HTTP requests). Analytics is necessary in today's site market and is indispensable; IMO it is not an option to forgo it.
As far as having your own "statistics app," I assume you're talking about building your own proprietary statistics codebase? I would discourage that, because it takes a lot of time and effort and in the end you will not have the same optimizations that Google has employed an entire project's worth of software engineers to make. Remember that while it's always great to create your own product, you don't have to reinvent the wheel, especially when it comes to things like this that have many sensible drop-in solutions that are widely available for free.
With respect to non-Google analytics solutions, one other of note is Clicky. I'm not as experienced with it as I am with GA, but I've heard many reviews that it is more precise and more informative than GA. However, just as an end-user browsing the web I've noticed a lot of times that its calls to Clicky's website do tend to slow down pages, and noticeably so; I cannot really say that I have seen the same effect with GA.
One last thing I would caution against is this: Do not employ more than one analytics solution unless you are trying to find the best one to suit your needs. It's just overkill to run two remotely-hosted analytics solutions on every single one of your pages, so what I would encourage you to do is try out a few for the first few weeks or so of your site (yes, pages will slow down during this trial phase) and then simply stick with the one that you like best. That will also give you the added benefit of being able to see first-hand what the speed implications are on your unique hosting environment for each script.
Here's some other analytics solutions that you might check out:
Piwik
Webtrends
GoingUp!
Yahoo! Web Analytics
Straight from Google's analytic sign up page (https://www.google.com/analytics/provision/)
"The appearance of your website will never be affected by your use of Google Analytics - we don't place any images or text on your pages. Likewise, the performance of your pages won't be impacted, with the possible exception of the very first page-load after you have added the tracking code. This first pageview calls the JavaScript on Google's servers, which may take slightly longer than a regular page load. Subsequent pageviews will use cached data and will not be affected."
Use the Asynchronous Snippet of Analytics:
http://code.google.com/apis/analytics/docs/tracking/asyncTracking.html
People focus to much on total load times when what is important is render times and in particular progressive rendering. If you use Google Analytics properly, it will load after the page has shown to the user. So yes, it will add a small overhead to every request but because the user can see the page already they probably won't even notice. Just go for it.
Webalizer runs on server side after apache logs doesn't it? That's why it appears outdated, it can't collect as much info as JS can. But it doesn't slow the user down any. You could run Webalizer and Google together for a bit and see what serves your needs best.
We decided to work around the possibility of google's servers appearing to slow our site down. Instead of our users downloading the ga.js file from google's servers we store it locally. The only problem with that approach is that our local copy becomes outdated. So we wrote an application that periodically compares our local file to google's and updates our file accordingly.
Andrew
Google Analytics is javascript based and does not tun on your server. All processing and storage is done on Google servers, so it's ideal if you are worrying about local resources.
The Yahoo Javascript library (YUI), JQuery and less so Google maps all allow you to reference their files using the following format:
<script type="text/javascript" src="http://yui.yahooapis.com/2.6.0/build/yahoo-dom-event/yahoo-dom-event.js"></script>
This does a request for the script from their servers, which will also pass to their web server the HTTP referrer. Do Yahoo etc. use this to produce statistics on which websites get what traffic? Or is this a conspiracy theory?
Of course their servers most of the time will be a lot faster than any small company would buy, so using the hosted version of the script makes more sense.
Chris,
I work on the YUI team at Yahoo.
We host only YUI on yui.yahooapis.com; Google hosts YUI and many other libraries on its CDN. I can tell you from the Yahoo side that we don't monitor site usage of YUI from our CDN. We do track general growth of yui.yahooapis.com usage, but we don't track which sites are generating traffic. You're right to suggest that we could track usage -- and we state as clearly as we can in our hosting docs that you should only use this kind of service if the traffic logs generated on our side don't represent a privacy concern for you.
In general, though, I don't regard CDN traffic for library usage to be a reliable measurement of anything. Most YUI usage, even at Yahoo, doesn't use yui.yahooapis.com or Google's equivalent, and I'm sure the same is true for other libraries. And even when a site is using YUI from our servers, we wouldn't have comprehensive traffic data of the kind you'd get from Google Analytics or Yahoo Analytics -- because not all pages would use YUI or the CDN uniformly.
Given the advantages of the hosted service -- including SSL from Google and YUI combo-handling from Yahoo -- I see the CDN as being a big win for most implementers, with little downside.
-Eric
Of course they produce statistics - at minimum they need to know how many resources they spend on hosting these scripts. And it's also nice to know who uses your code.
I don't think it's a bad thing.
And using a hosted version makes even more sense because your visitors might have the script already cached after visiting another site.
Sure, they can easily have statistics about which sites use YUI and how often, and also which parts of YUI API are more populare (among small sites). However, they cannot know what exactly web site visitors do with their libs.
Given, that they (Google & Yahoo) index a lot of web pages, they can get an even more precise statistics if they analyze their indexes. So you cannot hide that you are using YUI if your site is public.
The same applies to Google maps and jQuery.