PageSpeed Insights API: usability, security and metrics missing from json response - pagespeed

I am using PageSpeed Insights API to grab speed metrics of different websites and integrate the data in a tool I'm creating.
If I try a query using the API test tool (https://developers.google.com/speed/docs/insights/v4/reference/pagespeedapi/runpagespeed), then everything is fine and I get the info I need.
However, when I perform the very same query (as far as I can see) from my server, the response json does not include the same information. Some information is just missing.
Basically, other than the 'initial_url', all the metrics information that should be included in the 'loadingExperience' branch is missing. No info on 'FIRST_CONTENTFUL_PAINT_MS' or 'DOM_CONTENT_LOADED_EVENT_FIRED_MS'.
On the other hand, I can't seem to find the way to request info on USABILITY and SECURITY under the 'ruleGroups' branch. According to the API reference, this branch should feature information on these aspects too, but nothing like that is return after the query. Just the SPEED branch info is returned.
This is the URL I use to query the API:
https://www.googleapis.com/pagespeedonline/v4/runPagespeed?url=https://stackoverflow.com&strategy=mobile&screenshot=true&locale=en&key=XXXXXXXXmyAPIKeyXXXXXXXX';
Am I missing anything? I have checked the API documentation and Google'd for more info on this, but I can't seem to find any parameter to force request this information.
(By the way, this is my first question at StackOverFlow, so I hope I have shared all the necessary information. And apologies if my english is bad. I do my best.)

I'm having the same issue with some websites. The problem is related to the website. Some websites are providing the userExperience.metrics object and some are not. I have no idea what is causing this.
However you can try to use strategy=desktop parameter to get the userExperience.metrics object in version 5. This worked for me.
Working URL: https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://stackoverflow.com&strategy=desktop&key=[SetYourApiKeyHere]

Related

How do I get the name of the creative through the adcreativev2 API?

I am trying to find the API that lets me query for the creative name through the creative ID. When I used this API: https://api.linkedin.com/v2/adCreativesV2/{creative id}
It returned the information of the creative but the name is missing.
So basically after exploring endlessly the doc and available forums, it seems a name can be found using the API https://api.linkedin.com/v2/adDirectSponsoredContents/{URN}
where the URN can be found in the original https://api.linkedin.com/v2/adCreativesV2/{creative id}. It if the value of the field reference.
It seems unintuitive to have it in a separate endpoint instead of the original GET api. Hope it helps anyone who stumbles on this answer.
P.S Sometimes the API will return a 404 response to a perfectly existing ad, I don't know the cause exactly but when you view the ad on the campaign manager you will see that the creative name will have the value of the creative ID.
You are correct on how to get the creative names through the adCreativeV2 API. HOWEVER, this is literally being deprecated in about a week (2/28).
By the 28th, you have to migrate to the "versioned" LinkedIn API. https://learn.microsoft.com/en-us/linkedin/marketing/versioning?view=li-lm
The adCreativesV2 endpoint will fail. I still have no idea how to grab the creative names on the versioned API. I've reached out to LinkedIn.
Here are some of the changes: https://learn.microsoft.com/en-us/linkedin/marketing/versioning?view=li-lms-2023-02
I haven't been able to use the new creatives endpoint to get the creative name. It's even less precise than their old API, and since the share endpoints are being deprecated, I'm not sure where to go.
I'll update you if I hear back. Their API is frustrating and very poorly documented.
EDIT: You're getting 404s on some ads probably because those ads are NOT DSC. There are unfortunately multiple different endpoints you have to call to expose the creative contents depending on the ad type and if it's DSC or not. But as mentioned, this is all being deprecated in about a week, so I don't think it's worth implementing since it'll all break on the 28th when the old V2 endpoints are deprecated.

Troubleshooting Microsoft Cognitive Services Face API

Earlier today, I was able to send snapshots to the Face API and get responses including faceAttributes describing emotion.
I'm using JavaScript via XMLHttpRequest.
Now, though I've not changed the code, I get OK 200 from the API calls, but the responseText and the response properties are both, "[]".
I'd like to troubleshoot to see what I'm doing wrong, but it seems like the only information available in the cognitive services portal relates to quota.
Where should I look for further analytics?
You'll get an empty response if the API does not detect a face in the image or if the image file is too large (>4MB). You can confirm by testing with an image you know previously worked. To get the best results, make sure the face is well-lit and all features are reasonably visible.
Hello from Cognitive Services - Face API Team,
I wonder the problem belongs to one specific image or all API calls?
For a quick check, you can try the image on the online demo [1].
[1] https://azure.microsoft.com/en-us/services/cognitive-services/face/
Unfortunately doing the troubleshooting from the external perspective is quite difficult since you don't get any logs. The most common steps are to try to repro your problem using either the testing console (https://westus.dev.cognitive.microsoft.com/docs/services/563879b61984550e40cbbe8d/operations/563879b61984550f3039523b) or a tool such as curl or Fiddler so that you can see the raw REST request and response.
With one of those tools you can try to change up your request, try to call a different API, make sure there are no additional details being returned in the body or response headers, etc.
If all else fails please open a support incident from the Azure management portal and we can work with you.
We are also working to improve the logging and troubleshooting capabilities, but it may be some time to see improvements in this area.

What are practical use-cases for the HTTP verb REPORT and why is it neglected over time?

Whenever I have to create a RESTful web service and the use case implies on getting data based on a set of search criteria, I always opted for a POST request with the parameters in the body instead of a GET request for all the obvious reasons. I've seen it a dozen of times so I figured is was best practice.
Most recently I stumbled upon this interesting blog article by Evert Pot where he comments on the downsides of the POST verb and simply notes on using the REPORT verb instead. He also states that "its semantics are well defined and it works everywhere".
After reading the post I've been trying to find some more information on this REPORT verb but not much can be found. I know it was part of RFC-3253 as a way to obtain information about a resource but other than that I am clueless.
My question are the following:
Is REPORT really a better alternative than POST in the case of requesting a resource based on a set of search criteria?
Is it wise to start using it or is it too risky? I'm seeing lots of
HTTP Method REPORT not supported issues from various tools and frameworks.
Why does it seem like it is neglected over the years and why do we
know so little about it?
What could other valid use-cases be for using this verb?
Thank you in advance.
The REPORT method is defined in the webdav scope, including the Depth header field, and the DAV:version-tree report request.
Using it outside webdav you may incur in some unspecified behavior.
A REPORT request is an extensible mechanism for obtaining information
about a resource.
This is semantically different from a POST request, where you usually transfer the
expected representation you want to convey to the server.
Consider that in the HTTP method registry REPORT is marked as "safe" and "idempotent", while that's not the case for POST
the value of a report can depend on additional information
specified in the REPORT request body and in the REPORT request
headers.
Those are tied to webdav. To foster REPORT usage we should extend its definition and disentangle it from webdav.

Google Maps API V3 error: 403 (Forbidden access for too many pageviews)

I have a published layer in Google Maps Engine that I am attempting to display using the Google Maps V3 API. In GME, the layer's "Shared with" access list includes my user and the "API access" access list also includes by user.
I am making the Maps V3 API call using MapsEngineLayer from the visualization library, and setting the appropriate auth token and layer asset id as part of the layerOptions.
The API call is failing with the error message:
Google Maps API V3 error: 403 (Forbidden access for too many pageviews)
The URL looks like:
https://earthbuilder.googleapis.com/my_gme_layer_asset_id-4/maproot/json?
output=jsonp&access_token=my_auth_token&callback=xdc._tsel5i
I have found some discussion threads related to "403" and "forbidden", but am having difficulty figuring out the meaning of (and solution to) the "too many pageviews" issue.
Any suggestions would be appreciated.
If you tried with #David solution and it doesnt work. It worths to check that you are not caching (or storing locally) the google maps js script. Google don't allow that. If you serve that file it will work for about 3 days and then stop working.
How many requests have you made so far today, there are usage limits on the Maps API that may be preventing you from requesting any further data.
https://developers.google.com/maps/faq#usagelimits
Although it does seem unlikely that you have hit their hard set 25,000 requests, you may want to make sure that you aren't accidentally DOSing them with http requests. That sort of thing will invariably burn through your limit, and potentially place your IP on a blacklist.
Also, you should check the Maps API Reference materials, i think you may be trying to use a deprecated API.
https://developers.google.com/maps/documentation/webservices
Your http request should look more like this:
http://maps.googleapis.com/maps/api/service/output?parameters
Where output is either json or xml.
edit: The Maps API Help page is located here.

Is it a good idea to check the HTTP request query string and indicate an error once there's an unexpected parameter?

My ASP.NET application will have to handle HTTP GET requests that will have the following URL format:
http://mySite/getStuff?id="actualIdHere"
currently the requirement is to validate that there're no parameters in the query string except id and indicate an error like "unknown parameter P passed".
Is such requirement a good idea? Will it interfere with some obviously valid cases of using the application I haven't thought of?
It would be better to just validate the presence of id.
Validating unknown parameters doesn't serve much of a purpose, they will just be ignored.
Just edited my answer here:
There are also tracking solutions out there that will add to your query string.
One that comes to mind is web analytics.
If your application is going to be a public web site, you will want to implement some tracking of your traffic (e.g. google analytics).
If you want to implement a marketing campaign to draw traffic to your site, you will likely need to add a few parameters (specific to the tracking system you're using) to your querystring to check the effectiveness of your campaign.
It depends on your target audience.
It is not a good practice for public websites where you are aware of SEO, for example if you implement Google Analytics then a user come to your site from Search Results may have a parameter in URL like googleclid.
However in more protected websites it is fine.
It might affect forward compatiblity. For example, if you have separate client applications/websites that actually call this URLs, and future versions of these clients might provide additional parameters to getStuff (like a sort ordering, backlink, etc), making hard requirements on the parameters might make it harder to roll out new versions smoothly (i.e. cannot roll out new clients until the server is updated).
This in addition to the traffic forwarding parameters public websites might get as additional input, like the other answers mention.

Resources