django-silk VS lighthouse

Those docs are wrong. They still reference syncdb. Use the README at https://github.com/jazzband/django-silk.

If you're using Django as an API, without templates, django debug toolbar is useless because it requires templates. It won't work with DRF endpoints which means you miss out on profiling and SQL tracing. That's where django-silk shines.

https://github.com/ansible-community/ara/pull/358 https://github.com/b12io/orchestra/pull/830 https://github.com/batiste/django-page-cms/pull/210 https://github.com/carpentries/amy/pull/2130 https://github.com/celery/django-celery/pull/612 https://github.com/django-cms/django-cms/pull/7241 https://github.com/django-oscar/django-oscar/pull/3867 https://github.com/esrg-knights/Squire/pull/253https://github.com/Frojd/django-react-templatetags/pull/64 https://github.com/groveco/django-sql-explorer/pull/474 https://github.com/jazzband/django-silk/pull/550 https://github.com/keras-team/keras/pull/16073 https://github.com/ministryofjustice/cla_backend/pull/773 https://github.com/nitely/Spirit/pull/306 https://github.com/python/pythondotorg/pull/1987 https://github.com/rapidpro/rapidpro/pull/1610 https://github.com/ray-project/ray/pull/22396 https://github.com/saltstack/salt/pull/61647 https://github.com/Swiss-Polar-Institute/project-application/pull/483 https://github.com/UEWBot/dipvis/pull/216

Maybe look at https://github.com/jazzband/django-silk

Here's the non-psuedo code equivalent that can leverage CompressionStream rather than using a browserified-gzip-library: https://github.com/GoogleChrome/lighthouse/blob/437eb4d757c5...

We use it in Lighthouse for the exact same purpose, a URL #hash full of state. We found that modern browsers support 10mb of data in the hash. https://github.com/GoogleChrome/lighthouse/pull/12509#discus...

You can find out if your SaaS app is slowing down with Google Chrome Lighthouse. Lighthouse should be a staple in your monitoring because it lets you see the performance, accessibility, and SEO metrics related to your app's performance.

[2] https://github.com/GoogleChrome/lighthouse/issues/10023#issu...

Lighthouse: A tool developed by Google to measure a website’s performance using an average of six metrics.

Performance Using Lighthouse as a measurement tool, the blog should score 100 on all criteria.

For implementation testing (e.g. WCAG 2.1 compliance, performance, best sec practices) there are checkers like webhint, lighthouse, and Pa11y.

The website should score 80+ in performance, SEO, and accessibility in Google Lighthouse tests. Plus, the load time should always be less than 2 seconds and ideally in the order of a few hundreds of milliseconds. The real challenge lies here, since the website consists of more than 2 million pages, and pre-rendering them all will take weeks. Also, the content shown in most of the pages is not static. Thus, we opted for an incremental static regeneration approach. When a visitor hits a page no one ever visited, Next.js generates it with the data retrieved from the APIs exposed by the backend. Then, Next.js caches the page for 30 or 60 seconds, depending on the importance of the page.

Lighthouse tests are a helpful method to measure your web vitals — you can run Lighthouse tests from Chrome DevTools, via the Lighthouse Chrome Extension, or in the command line:

Now let's check if we properly set up our PWA using a Google Lighthouse check. Right-click on your browser and select "inspect." On the inspect tabs, select lighthouse and click on generate report. If everything went well with your application, you should see an output like the one in the screenshot below: