Move https://github.com/xwp/site-performance-tracker/blob/16931538f90de1d20a1c012f62cc854436dd4ec2/php/views/settings.php into something like php/src/class-settings.php which is bootstrapped during:

When activating the plugin I get these errors:

Fatal error: Uncaught Error: Class 'Site_Performance_Tracker\Plugin' not found in /app/public/wp-content/plugins/site-performance-tracker-master/site-performance-tracker.php on line 60

Error: Class 'Site_Performance_Tracker\Plugin' not found in /app/public/wp-content/plugins/site-performance-tracker-master/site-performance-tracker.php on line 60

Let me know if I can help troubleshoot.

Right now the debug receives the largestSource.node, but most of the times this comes from a paragraph in the article content it makes it harder to identify which of the elements above it is the most problematic
https://github.com/xwp/site-performance-tracker/blob/master/js/src/web-vitals-analytics.js#L138
An idea is to look if the target node has an immediate previous sibbling, and if it exists, to deliver that instead to the debug data. This way we have the path to what might be quite the element causing the shift (or at the very least one step closer to it).

Apply Exclusions by attribute

<script nowprocket src='

to the script tags for this plug-in.

After the latest version (0.1.1+), the UI of the interface doesn't reflect the hard-coded values, showing the placeholders as if it wasn't already configured

It seems duplicate event categories are reported, one as Web Vitals and other as general. Any particular reason for general category?

Currently, when GA4 Analytics is selected in the plugin settings, the three custom dimensions input fields are showing. With GA4, we don't need to set up the custom dimensions since they are already included. This is only needed when GA and GTM are selected.

Acceptance Criteria

1. Do not show the following input fields in the settings UI when GA4 Analytics is selected under Analytics Types:

• Measurement Version
• Event Meta
• Event Debug

2. Ensure that when GA4 is selected, and inputs added, the settings can successfully save after removal of the custom dimensions input fields

Add support for tracking Web Vitals.

I think it would be beneficial to have a filter on the PerformanceNavigationTiming events array so that a user is able to alter the types of events that are being tracked. Currently only a three events are tracked by default:

• domContentLoadedEventEnd
• domInteractive
• domComplete

Here's a reference of event types that the PerformanceNavigationTiming exposes: https://developer.mozilla.org/en-US/docs/Web/API/PerformanceNavigationTiming

This way it will be easier to update and receive bug fixes from the users of the plug-in.

Fixes - https://xwp-co.atlassian.net/browse/INITS-2416

In a recent thread, there's a reference to the "attribution build" which can provide more information on the INP tracked information:
https://twitter.com/tunetheweb/status/1764757818303717863

We're loading the standard web-vitals library ourselves
https://github.com/xwp/site-performance-tracker/blob/master/js/src/measure-web-vitals.js#L2

As a side-effect of this, we'll need to update our switch to deliver the CLS / INP and LCP attribution instead of calculating ourselves "which" attribution should be reported:
https://github.com/xwp/site-performance-tracker/blob/master/js/src/send-to-analytics.js#L103-L140

We should lint PHP and potentially run tests on Travis to ensure that all code matches the coding standards.

Time to First Byte (TTFB) is not reported, any plan to include support?

Keep the code-activated piece in, that will continue to be supported.

Do the check that ga / gtag exists before the data is sent.

Using hooks such as do_action( 'site_performance_mark', 'position' ); instead of conditional methods calls would allow disabling the plugin on production and avoid any PHP errors if the plugin is not enabled.

Selecting from a dropdown between the 3 analytics types
Fill in the specific analytics ID
Depending on the selection, entering the numbers of the custom dimensions needed to send the debug data in.
Have an input to pick the ratio (0->1) of tracking for the web vitals.

Should contain a link to the web vitals report, and information surrounding the fact that the data range should only start for the dates when web vitals data is being sent.

1. Plugin::the_performance_mark
2. Plugin::get_the_performance_mark

Could helpers be deleted?

According to the Google Developer Guides the only way to track Time To Interactive (TTI) is to use a polyfill.

We should have a way to add the TTI metric along with adding the polyfill as an opt-in feature. I guess it could be another item in the $entry_types array. We currently filter this array using:

apply_filters( 'site_performance_tracker_event_types', array $entry_types = [ 'paint', 'navigation', 'mark' ] );

It will be nice to catch issues using the WordPressVIPMinimum ruleset. I propose to migrate the code sniffer to validate code for WordPress VIP.

Repository - https://github.com/Automattic/VIP-Coding-Standards

The GA delivery function throws an error Command ignored. Unknown target: undefined when running the tracker using custom dimensions. The ga delivery function may need some adjustment as described here so as to rid of the error.

This will need to be tested using the feature branch in a site, before merging it in.

https://github.com/xwp/site-performance-tracker/security/dependabot

It looks like pageviews that fire the Web Vitals Event tend to report much higher Pages / Session. Any idea why that would be or if there’s something you can tweak to make it line up more with “normal” traffic patterns?

Seems like there should be a way to send the data without sending an extra pageview

Idea: maybe look at “non-interaction event” in GA, if it’s not already being sent that way

Once GoogleChrome/web-vitals#323 is merged and in a tagged release, we should move away from hard-coding thresholds in the plugin and instead reuse the exported thresholds directly. This ensures we wont miss an update to these thresholds and always measure against the latest recommendations.

When choosing the GA in the UI

The output is as follows
{"analytics_types":"ga_id","gtag_id":"UA-XXXXXXX-1"

The script expects this to have the ID stored under the ga_id attribute instead:
https://github.com/xwp/site-performance-tracker/blob/master/js/src/send-to-analytics.js#L149

The plugin currently must be installed as a Composer dependency and it won't work without the PSR-4 autoloader. We should update the readme to include clear installation instructions.

Would you welcome a PR that removes

add_action( 'wp_enqueue_scripts', array( $this, 'enqueue_scripts' ) );

and adds this?

/**
 * Enqueue javascript to trigger web vitals tracking.
 *
 * @hook wp_enqueue_scripts
 */
public function enqueue_scripts() {

https://amp.dev/documentation/examples/advertising-analytics/tracking_core_web_vitals/

We are currently only tracking performance data outside of AMP.

This will gather data (possibly all of it) from AMP, and requires a filter to toggle it on or off.

GA4 requires a little different data to be sent to compared to GTAG
https://github.com/GoogleChrome/web-vitals#using-gtagjs-google-analytics-4
vs
https://github.com/GoogleChrome/web-vitals#using-gtagjs-universal-analytics

Thinking initialising the theme support with ga4_id instead of gtag_id could serve behind this extension.

This is inspired by this very good article which includes the templates to build the BigQuery datastudio dashboard:
https://bigcommerce.websiteadvantage.com.au/tag-rocket/articles/core-web-vitals-ga4-bigquery-data-studio/

Describe Google Analytics setup requirements (probably in the readme.md).

• Do we currently only support sites that have ga() defined in the <head>?
• Do we support the new gtag.js tags?

Simple unit tests need no database.
https://github.com/Automattic/wordbless makes it possible!

The scope for this is bypassing long caches when updating the plug-in.

Version 2.0+ of the web vitals JS library now measures the CLS with the new max session 5s cap 1s gap - https://github.com/GoogleChrome/web-vitals/blob/main/CHANGELOG.md#v200-2021-06-01

Specific breaking change:
GoogleChrome/web-vitals#148

Some composer dependencies fail to build with the newer composer version

The tracker code is not loading when installed via composer, as suggested in the readme.

When installed via WP Admin » Plugins, things work as expected.

The web vitals JS library has added support for INP:
https://github.com/GoogleChrome/web-vitals#oninp

So does the report site:
https://web-vitals-report.web.app/

Update and deliver the INP through this tracking.

Caused by not checking whether some of the expected settings values are set on the settings object. I am also contributing a fix in a separate PR.

It might me a case that requestIdleCallback is executed right away and the lighthouse is picking up the change of src attribute, maybe we should change this to window.addEventListener('load') or setTimeout and inside that use requestIdleCallback with some timeout option?

https://github.com/xwp/site-performance-tracker/blob/master/php/Plugin.php#L84

When configuring GA4 ID, the setting does not persist in the administrative interface:

The setting is saved in the database and used for outputting the code correctly

","ga4_id":"UA-1234588"},"chance":"1"};

Problem is reproducible with version 1.3.

Probably it's around this area of the code:
https://github.com/xwp/site-performance-tracker/blob/master/php/src/class-analyticsidfield.php#L53C9-L55

We should load the vendor/autoload.php only if it exists, to support projects that have root-level autoload and this plugin is part of the dependency list:

would become:

if ( file_exists( __DIR__ . '/vendor/autoload.php' ) ) {
    require_once __DIR__ . '/vendor/autoload.php';
}

As per a recent WordPress VIP review of the plugin, an issue has been raised that we shouldn't use esc_js() in Plugin.php, L165:

return sprintf( "<script>performance && performance.mark( 'mark_%s' );</script>\n", esc_js( $mark_slug ) );

Instead, as per VIP best practices we should use wp_json_encode().

Currently we only support installation through Composer, see #11.

We need to add a build step that runs only on tags that creates a plugin distribution ZIP that contains all the dependencies. Also fixes #14 and #15.

The minimum Web Vitals Tracking Ratio possible right now is 0.01.
There are client's sites with enough visits to pass the recommended 30k tracked events per day using "0.01", therefore we bump into :

Allow smaller ratios.