googlechrome / lighthouse-stack-packs Goto Github PK

Reading through wordpress/audits.json, I stumbled upon this item:

This is applicable not only for WordPress, but for any PHP framework being used (or server-side language for what it's worth).

Would it make sense to create some sort of hierarchy for audits messages, and output the merged advices? (i.e php/audits.json would contain that item, and wordpress/audits.json would include it)

That could also make Lighthouse give some accurate recommendations even when the framework is not detected, or only partially matched.

cc @housseindjirdeh

https://github.com/GoogleChrome/lighthouse-stack-packs/blob/master/packs/magento.json#L8

Use Terser to minify all JavaScript assets outfrom from static content deployment, and disable the built-in minification feature.

should be something like:

Use Terser to minify all JavaScript assets from static content deployment, and disable the built-in minification feature.

should be server-response-time

GoogleChrome/lighthouse#11396 (comment)

could fix this with usage of currentColor but that does not work with data urls https://stackoverflow.com/questions/49381592/currentcolor-in-background-image-svg . Perhaps LH could extract the svg from the data url and append to the page as an element instead, then we could use currentColor. Other options exist, see link

other logos should be checked

Specific-Guidance based on WordPress Page Builder Used:

1. Initial support and performance recommendations for Gutenberg, Elementor, Divi frameworks. Other major page builder-specific recommendations to follow in future updates?

2. Accessibility Standards Analysis for WordPress-specific issues- identify any existing accessibility issues on the analyzed page.

WPCampus, Matt Mullenweg, and WP users recently donated for and released the results of a major accessibility audit which found that Gutenberg is lacking severely in many Accessibility areas: https://wpcampus.org/2019/05/gutenberg-audit-results/

Assertions require every name in the call target to be declared with an explicit type annotation.

when trying to publish.

at first glance the deletion / then regenerate bit seems odd. I am in a bit of a rush so I'll hack around it for the next release for now

Creating this issue to consolidate a master list of stacks/platforms to consider supporting moving forward. This is by no means final and can change at anytime, but it's probably helpful to have a rough list :).

• CMS/E-commerce
  • WordPress
  • Magento
  • Drupal
  • Shopify
  • Joomla
  • TYPO3
• Site builders
  • Wix
• JS frameworks/libraries
  • Angular
  • React
  • Vue

If you have any suggestions for adding/removing any stack on this list, please don't hesitate to let us know.

Hello,

Where can I download a list of all the latest Lighthouse checklists to be able to write our cms pack.

I can give an extra of what I'm talking about, the Wordpress pack says the following:

Metrics

• Estimated Input Latency
• First Contentful Paint
• First CPU Idle
• First Meaningful Paint
• Time to Interactive
• Speed Index

However this is out of date as Google has since created new and exciting metrics such as the Cumulative Layout Shift API etc.

Where can I get a list of all the Lighthouse checks to be able to write an up to date stack pack and also be able to update it with new checks being added in future releases.

Thanks.

Just going to link this issue to our cms to make tracking easier: octobercms/october#4959

Starting a stub issue here at the Google CMS Leadership summit for exploring a stack pack for Drupal.

One of the concerns for Drupal as a project is Drupal is not an opinionated CMS out of the box. Different use cases on top of Drupal might have very different audit requirements and recommendations.

Before we could move forward further we’d need to understand the right architectural approach for handling this variance.

Thanks again @moerazem for putting a Drupal pack together!

As we previously discussed, do you think we could modify a few of the suggestions to not mention a single module but instead point to a search link or something similar? This would ensure we don't pick favorites and at the same time make things a little more fool-proof if any of these modules become unmaintained/deprecated.

Although I already merged it and it all looks great, I left some additional comments on the PR. Will defer to you for your expertise so feel free to not consider any of my suggestions if they don't make sense :)

To kick-off the next step of including stacks for more than just CMS platforms, it would be great to have a React stack as the first entry for a JavaScript framework. It already meets almost all of the requirements.

TODO list:

• Add React to library detector
• Have community members land on final secondary recommendations for most of the performance audits

AMP caches (e.g. Google AMP Cache) apply optimizations on top of the AMP content they ingest, which can also be run locally via amp optimizer. We should..

(a) Recommend use of amp optimizer in audits that may be affected by its absence, or (b) perhaps detect and flag its absence as a top level recommendation?

@sebastianbenz @pbakaus

see GoogleChrome/lighthouse#15038 (comment)

"redirects": "If you are using React Router, minimize usage of the `<Redirect>` 
component for 
[route navigations](https://reacttraining.com/react-router/web/api/Redirect).",

Should it be router navigations in the link?

Per discussions with the Angular team, it would be great to see the framework as one of the earlier JavaScript framework entries here.

Having code-spans inside a [link]() will not render properly in Lighthouse.

...use [`amp-anim`](https://www.ampproject.org/docs/reference/components/amp-anim) to minimize...",

...the [`amp-font`](https://www.ampproject.org/docs/reference/components/amp-font#on-load-add-class) component..."

I support this being added as a feature in our i18n parser, but this syntax won't work in the current status quo.

Hello pls do add support for Joomla CMS www.joomla.org

I made a comment in the spreadsheet, but I felt like it might be worth more of a discussion–

Typically when I run into the Avoid enormous network payloads detection in Lighthouse it's usually due to the content manager using overly large images or embedded videos.

The WordPress Description currently recommends reducing the number of posts and using excerpts which certainly wouldn't be a bad suggestion, but I think that would have more of an affect on TTFB unless there were many images within each post being queried.

Perhaps we could mention something about avoiding large images and large videos– possibly even recommending videos be hosted on services like Youtube to reduce their footprint on initial load? In my pull request I did add a note to avoid Full Size images in the WYSIWYG unless they are adequately sized. This could be relevant here too.

One requirement for adding a stack pack is reliably detecting that the stack/library/platform is being used by the page. We want this detection to be as reliable and bulletproof as possible.

Wappalyzer uses a few approaches which seem overkill and not something we can reuse. We'd like something much more lightweight.

Primary question: Can we detect wordpress via via clientside JS running in the page? (Naturally, it has full access to window and the DOM.)

Secondary question: Is there another reliable detect based on the network request metadata? We'd like to avoid parsing the response of any network resources (so no looking for patterns in HTML, JS or CSS files). But considering
response headers or paths in urls (like wp-content, etc) is fine.

Could some WordPress experts chime in?

Add support for Ember.js performance and other improvements in sites.

Thanks!

Transfer from GoogleChrome/lighthouse#12473

We have an initial set of React-specific suggestions! However, we would love to have more members from the community review and add more if possible.

1. Do the already populated performance audit suggestions look good? Should they be changed in any way?
2. For all the remaining performance audits (currently blank), can we add a React-specific suggestion that would be relevant to developers?

All thoughts, comments and PRs appreciated!

A number of WordPress-specific audit messages include a link to the search results page at wordpress.org/plugins. Now that the WordPress Performance working group has built the Performance Lab plugin, I'd like to see Lighthouse making a more opinionated recommendation to use that specific plugin where applicable.

For example, the modern-image-formats audit has a WordPress stack pack message of:

Consider using a plugin or service that will automatically convert your uploaded images to the optimal formats.

The Performance Lab plugin promotes a module that does exactly that:

WebP Uploads: Creates WebP versions for new JPEG image uploads if supported by the server.

cc @adamsilverstein @felixarntz @ThierryA

Looking for a guide/suggestions on how to use this tool. Thank you.

Hey there,

Trying to render a JSON report generated using Lighthouse 5 in the viewer hosted on Github.
I made a public Gist with the content of the Lighthouse response object, but an error pops up: Is not a valid URL.

Here is the link: https://houssein.me/lighthouse/viewer-wordpress/?gist=ee3e6c422749f7a0fc6dcf68097cef8b

Do you have an idea where this issue originates from?

On another subject, I am using this React package to render Lighthouse reports. How can I render a report with the Wordpress recommendations?

Cheers, and thanks for your work

Improve docs to add a section of 'offline' stack packs where you can create your own plugin but not necessarily needs to be added to Lighthouse.

Opening this issue to have a place where people can leave general suggestions 💬.

Some preliminary thoughts to kick things off:

• Which platforms should we support?
  • After WordPress, we can continue to target other CMS platforms (like Drupal) as well as explore how to include suggestions for JavaScript frameworks (Angular, React, etc...). Anything else?
• Should we show a toggle to switch between the original Lighthouse report and an updated one with platform-specific strings included? Or should we always surface platform-specific audit messages if a tool is detected on the webpage?

Note: For details on how platform packs will be integrated into core, take a look at the RFC.

The second half of the string https://github.com/GoogleChrome/lighthouse-stack-packs/blob/master/packs/drupal.js#L28 is unclear.

Use the Responsive Image Styles when rendering image fields through view modes, views, or images uploaded through the WYSIWYG editor.',

Are there three ways of rendering an image field? (through a view mode, a view, or via upload from the WYSIWYG editor) Or is the WYSIWYG editor different and is uploading images directly instead of through fields?

This needs to be re-written by someone who knows what all these Drupal terms mean 😄