Tnolet/seo perf fixes sc00 (#1164)

* style: remove unused styles * feat: remove layout shifting button swap * refactor: clean up header order * style: mini color fix * fix: don't load sidemenu code on splash page * fix: remove unused code. Fix errors on non-existing menus * feat: remove unneeded resources. 1st stage revamp mobile menu. * feat: adds missing files. * fix: fixes docsearch css race condition. * fix: fixes scrolltop error. * style: try to fix race condition. * style: try to fix race condition #2.
checkly · Jan 7, 2025 · 3c7b2f5 · 3c7b2f5
1 parent 08fbbca
commit 3c7b2f5
Show file tree

Hide file tree

Showing 77 changed files with 455 additions and 1,282 deletions.
diff --git a/gulpfile.mjs b/gulpfile.mjs
@@ -56,13 +56,6 @@ gulp.task('minify-css', () => {
     .pipe(gulp.dest('./public/css'))
 })
 
-// Copy Third Party Javascript
-
-gulp.task('copy-js', function () {
-  return gulp.src('./src/js/xml2json.js')
-    .pipe(gulp.dest('./public/js'))
-})
-
 // Compile Javascript
 gulp.task('js', (cb) => {
   const myConfig = Object.assign({}, webpackConfig)
@@ -125,14 +118,14 @@ gulp.task('watch', () => {
 })
 
 // Development server with browsersync
-gulp.task('server', gulp.series(['hugo', 'css', 'copy-js', 'js', 'fonts', 'purgecss', 'minify-css', 'serve', 'watch']))
+gulp.task('server', gulp.series(['hugo', 'css', 'js', 'fonts', 'purgecss', 'minify-css', 'serve', 'watch']))
 
 gulp.task('clean', () => {
   return del(['./public/**/*'])
 })
 
 // Build/production tasks
-gulp.task('render', gulp.series(['css', 'copy-js', 'js', 'fonts', 'hugo', 'purgecss', 'minify-css']))
+gulp.task('render', gulp.series(['css', 'js', 'fonts', 'hugo', 'purgecss', 'minify-css']))
 gulp.task('build', gulp.series(['clean', 'render', 'hash']))
 
 /**

diff --git a/site/content/docs/CICD/vercel-deployment-protection.md b/site/content/docs/CICD/vercel-deployment-protection.md
@@ -7,7 +7,7 @@ menu:
   integrations:
     parent: "Vercel"
     identifier: vercel-deployment-protection
-cli: true
+
 ---
 
 In some cases, you will need to provide authentication credentials to your Vercel deployment in order to run your browser

diff --git a/site/content/docs/alerting-and-retries/_index.md b/site/content/docs/alerting-and-retries/_index.md
@@ -7,7 +7,7 @@ slug: /
 menu:
   resources:
    parent: "Alerting & retries"
-cli: true
+
 aliases:
   - /docs/alerting/
 ---

diff --git a/site/content/docs/alerting-and-retries/alert-channels.md b/site/content/docs/alerting-and-retries/alert-channels.md
@@ -6,7 +6,7 @@ weight: 31
 menu:
   resources:
     parent: "Alerting & retries"
-cli: true
+
 ---
 
 Alert channels are the channels through which alert notifications will reach you when a check starts failing, showing degraded performance or recover.

diff --git a/site/content/docs/alerting-and-retries/alert-settings.md b/site/content/docs/alerting-and-retries/alert-settings.md
@@ -9,7 +9,7 @@ menu:
 aliases:
 - /alerting/settings/
 - /alerting/
-cli: true
+
 ---
 
 Alert settings allow you to control when and how often you will be notified when a check starts failing, degrades or recovers.

diff --git a/site/content/docs/alerting-and-retries/retries.md b/site/content/docs/alerting-and-retries/retries.md
@@ -6,7 +6,7 @@ weight: 32
 menu:
   resources:
    parent: "Alerting & retries"
-cli: true
+
 ---
 
 Sometimes the internet is flaky, or your app is just having a hiccup not worth pinging your on-call team about. Retries are your first line of defense against these types of false positives, leading to alert fatigue.

diff --git a/site/content/docs/alerting-and-retries/webhooks.md b/site/content/docs/alerting-and-retries/webhooks.md
@@ -6,7 +6,7 @@ weight: 35
 menu:
   resources:
     parent: "Alerting & retries"
-cli: true
+
 ---
 
 Webhooks allow you to POST custom payloads to any endpoint in your own infrastructure or a third party provider. In a

diff --git a/site/content/docs/api-checks/_index.md b/site/content/docs/api-checks/_index.md
@@ -10,7 +10,7 @@ menu:
     identifier: overview-api-checks
 aliases:
 - 'docs/api-checks'
-cli: true
+
 ---
 
 API checks consist of few parts:

diff --git a/site/content/docs/api-checks/assertions.md b/site/content/docs/api-checks/assertions.md
@@ -6,7 +6,7 @@ weight: 10
 menu:
   resources:
     parent: "API checks"
-cli: true
+
 ---
 
 The response of an API request can be checked for correctness and timeliness by using assertions on the response data. Assertions are flexible statements that combine preset modifiers with custom values to meet the needs of a broad set of use cases.

diff --git a/site/content/docs/api-checks/limits.md b/site/content/docs/api-checks/limits.md
@@ -6,7 +6,7 @@ weight: 11
 menu:
   resources:
     parent: "API checks"
-cli: true
+
 ---
 
 

diff --git a/site/content/docs/api-checks/request-settings.md b/site/content/docs/api-checks/request-settings.md
@@ -6,7 +6,7 @@ weight: 8
 menu:
   resources:
     parent: "API checks"
-cli: true
+
 ---
 
 

diff --git a/site/content/docs/api-checks/setup-script-examples.md b/site/content/docs/api-checks/setup-script-examples.md
@@ -7,7 +7,7 @@ menu:
   resources:
     parent: "Setup & teardown scripts"
     identifier: setup-script-examples
-cli: true
+
 ---
 
 Here are some examples on how to address common authentication use cases with setup scripts. 

diff --git a/site/content/docs/api-checks/setup-teardown-scripts.md b/site/content/docs/api-checks/setup-teardown-scripts.md
@@ -6,7 +6,7 @@ weight: 12
 menu:
   resources:
     parent: "API checks"
-cli: true
+
 ---
 
 Setup and teardown scripts can be used to execute arbitrary JavaScript/TypeScript code before and/or after an API check. 

diff --git a/site/content/docs/api-checks/teardown-script-examples.md b/site/content/docs/api-checks/teardown-script-examples.md
@@ -7,7 +7,7 @@ menu:
   resources:
     parent: "Setup & teardown scripts"
     identifier: teardown-script-examples
-cli: true
+
 ---
 
 ## Update response status

diff --git a/site/content/docs/api-checks/timeouts-timing.md b/site/content/docs/api-checks/timeouts-timing.md
@@ -6,7 +6,7 @@ weight: 13
 menu:
   resources:
     parent: "API checks"
-cli: true
+
 ---
 
 All API checks are capped at a timeout of **30 seconds**. With each request, we record the most relevant timing phases. This can help you troubleshoot slow responses, e.g. your DNS might be slow.

diff --git a/site/content/docs/api-checks/variables.md b/site/content/docs/api-checks/variables.md
@@ -7,7 +7,7 @@ menu:
   resources:
     parent: "API checks"
     identifier: variables-api-checks
-cli: true
+
 ---
 
 Multiple API checks can target the same server/service. In this case, your checks might need the same configuration item

diff --git a/site/content/docs/browser-checks/_index.md b/site/content/docs/browser-checks/_index.md
@@ -10,7 +10,7 @@ menu:
 aliases:
     - /docs/browser-checks/quickstart/
     - /docs/browser-checks/getting-started/
-cli: true
+
 ---
 
 This guide gives you all the info to create your first Browser check with Checkly. You should have some prior

diff --git a/site/content/docs/browser-checks/degraded-state.md b/site/content/docs/browser-checks/degraded-state.md
@@ -7,7 +7,7 @@ menu:
   resources:
     parent: "Browser checks"
     identifier: "browser-degraded-state-soft-asserts"
-cli: true
+
 ---
 
 If you want to monitor your service for non-critical errors or performance degradations you can use the degraded check state. This allows you to signal that parts of a Browser check performed slower than expected, or that it triggered assertions that are of lower criticality. 

diff --git a/site/content/docs/browser-checks/file-system.md b/site/content/docs/browser-checks/file-system.md
@@ -8,7 +8,7 @@ menu:
     parent: "Browser checks"
 aliases:
   - /docs/browser-checks/file-system/
-cli: true
+
 ---
 
 You might want to use (binary) files in your browser checks. For example, you might want to upload a file to an upload 

diff --git a/site/content/docs/browser-checks/login-scenarios.md b/site/content/docs/browser-checks/login-scenarios.md
@@ -8,7 +8,7 @@ aliases:
 menu:
   resources:
     parent: "Browser checks"
-cli: true
+
 ---
 
 Scenarios where a user provides credentials to get access to a web app are extremely common. They are also

diff --git a/site/content/docs/browser-checks/multiple-tabs.md b/site/content/docs/browser-checks/multiple-tabs.md
@@ -8,7 +8,7 @@ aliases:
 menu:
   resources:
     parent: "Browser checks"
-cli: true
+
 ---
 
 Certain scenarios may require us to create new or multiple tabs simultaneously. Playwright Test supports this case and, as a consequence, Checkly does as well.

diff --git a/site/content/docs/browser-checks/playwright-test.md b/site/content/docs/browser-checks/playwright-test.md
@@ -7,7 +7,7 @@ weight: 14
 menu:
   resources:
     parent: "Browser checks"
-cli: true
+
 ---
 
 Checkly natively supports running browser checks using the Playwright Test Runner, allowing you to write tests and use 

diff --git a/site/content/docs/browser-checks/scraping-onpage-elements.md b/site/content/docs/browser-checks/scraping-onpage-elements.md
@@ -7,7 +7,7 @@ weight: 15
 menu:
   resources:
     parent: "Browser checks"
-cli: true
+
 ---
 
 Any standard Node.js script that successfully finishes an execution is a valid, passing browser check. However, in

diff --git a/site/content/docs/browser-checks/screenshots.md b/site/content/docs/browser-checks/screenshots.md
@@ -6,7 +6,7 @@ weight: 19
 menu:
   resources:
     parent: "Browser checks"
-cli: true
+
 ---
 
 You can take up to 20 screenshots per browser check run. This is really handy when debugging a failure situation or just

diff --git a/site/content/docs/browser-checks/timeouts.md b/site/content/docs/browser-checks/timeouts.md
@@ -6,7 +6,7 @@ weight: 24
 menu:
   resources:
     parent: "Browser checks"
-cli: true
+
 ---
 
 There are different kinds of timeouts you will encounter while working with Browser checks:

diff --git a/site/content/docs/browser-checks/tracing-web-vitals.md b/site/content/docs/browser-checks/tracing-web-vitals.md
@@ -7,7 +7,7 @@ menu:
   resources: 
     parent: "Browser checks"
     identifier: tracing-web-vitals-browser-checks
-cli: true
+
 ---
 
 For all your browser checks we automatically collect a comprehensive set of data like **console logs and network requests** 

diff --git a/site/content/docs/browser-checks/variables.md b/site/content/docs/browser-checks/variables.md
@@ -7,7 +7,7 @@ menu:
   resources:
     parent: "Browser checks"
     identifier: variables-browser-checks
-cli: true
+
 ---
 
 When creating browser checks, you probably run some code locally, store it in a Git repo or copy and paste it around

diff --git a/site/content/docs/browser-checks/visual-regression-snapshot-testing.md b/site/content/docs/browser-checks/visual-regression-snapshot-testing.md
@@ -6,7 +6,7 @@ weight: 25
 menu:
   resources: 
     parent: "Browser checks"
-cli: true
+
 aliases:
    - "/docs/browser-checks/visual-comparison-snapshot-testing/"
 ---

diff --git a/site/content/docs/dashboards/_index.md b/site/content/docs/dashboards/_index.md
@@ -12,7 +12,7 @@ aliases:
   - "/dashboards/overview/"
   - "/docs/dashboards/overview/"
   - "/docs/dashboards/"
-cli: true
+
 ---
 
 You can use Checkly Dashboards to communicate check status and incidents to non-Checkly users. Use

diff --git a/site/content/docs/dashboards/custom-css.md b/site/content/docs/dashboards/custom-css.md
@@ -6,7 +6,7 @@ weight: 49
 menu:
   resources:
     parent: "Dashboards"
-cli: true
+
 ---
 
 You can completely customize the look & feel of your dashboard using custom CSS rules so the dashboard fits your company's

diff --git a/site/content/docs/dashboards/dashboard-customization.md b/site/content/docs/dashboards/dashboard-customization.md
@@ -6,7 +6,7 @@ weight: 47
 menu:
   resources:
     parent: "Dashboards"
-cli: true
+
 ---
 
 ## Checkly URL

diff --git a/site/content/docs/dashboards/incidents.md b/site/content/docs/dashboards/incidents.md
@@ -6,7 +6,7 @@ weight: 50
 menu:
   resources:
     parent: "Dashboards"
-cli: true
+
 ---
 
 Using **Incidents** you can communicate outages and planned maintenance to your audience — customers, co-workers, partners —

diff --git a/site/content/docs/groups/_index.md b/site/content/docs/groups/_index.md
@@ -10,7 +10,7 @@ menu:
     identifier: overview-groups
 aliases:
 - /docs/groups/
-cli: true
+
 ---
 
 Groups allow you to organize your checks and centralize settings like base URL's, headers, variables and other properties

diff --git a/site/content/docs/groups/api-check-defaults.md b/site/content/docs/groups/api-check-defaults.md
@@ -6,7 +6,7 @@ weight: 27
 menu:
   resources:
     parent: "Groups"
-cli: true
+
 ---
 
 Using a set of shared defaults for API checks helps you manage checks that go to the same basic 

diff --git a/site/content/docs/groups/variables.md b/site/content/docs/groups/variables.md
@@ -7,7 +7,7 @@ menu:
   resources:
     parent: "Groups"
     identifier: variables-groups
-cli: true
+
 ---
 
 You can set both variables and secrets for a Group of checks.

diff --git a/site/content/docs/heartbeat-checks/_index.md b/site/content/docs/heartbeat-checks/_index.md
@@ -11,7 +11,7 @@ menu:
 aliases:
     - /docs/heartbeat-checks/quickstart/
     - /docs/heartbeat-checks/getting-started/
-cli: true
+
 ---
 
 This guide gives you all the info needed to get started with Checkly heartbeat checks.

diff --git a/site/content/docs/maintenance-windows/_index.md b/site/content/docs/maintenance-windows/_index.md
@@ -10,7 +10,7 @@ menu:
     identifier: overview-maintenance-windows
 aliases:
 - /docs/maintenance-windows/
-cli: true
+
 ---
 
 You can schedule planned maintenance for your API, app or website using Checkly's maintenance windows. During maintenance 

diff --git a/site/content/docs/multistep-checks/_index.md b/site/content/docs/multistep-checks/_index.md
@@ -11,7 +11,7 @@ menu:
 aliases:
     - /docs/multistep-checks/quickstart/
     - /docs/multistep-checks/getting-started/
-cli: true
+
 ---
 
 This guide gives you all the info to create your first Multistep check with Checkly. You should have some prior

diff --git a/site/content/docs/multistep-checks/degraded-state.md b/site/content/docs/multistep-checks/degraded-state.md
@@ -7,7 +7,7 @@ menu:
   resources:
     parent: "Multistep checks"
     identifier: "multistep-degraded-state-soft-asserts"
-cli: true
+
 ---
 
 If you want to monitor your API for non-critical errors or performance degradations you can use the degraded check state. This allows you to signal that parts of a Multistep check performed slower than expected, or that it triggered assertions that are of lower criticality. 

diff --git a/site/content/docs/multistep-checks/example-checks.md b/site/content/docs/multistep-checks/example-checks.md
@@ -7,7 +7,7 @@ menu:
   resources:
     parent: "Multistep checks"
     identifier: "multistep-example-checks"
-cli: true
+
 ---
 
 Below are a number of checks showcasing how to use Multistep checks. These are similar to the templates provided in Checkly when creating a new Multistep check and should give you an idea of how to get started building various types of checks.

diff --git a/site/content/docs/multistep-checks/upload-downloads-filesystem.md b/site/content/docs/multistep-checks/upload-downloads-filesystem.md
@@ -7,7 +7,7 @@ menu:
   resources:
     parent: "Multistep checks"
     identifier: "multistep-checks-uploads"
-cli: true
+
 ---
 
 You might want to use (binary) files in your Multistep checks. For example, you might want to upload a file to an API endpoint using a binary body. Or, you might want to validate some aspect of a file that is available for download on your

diff --git a/site/content/docs/multistep-checks/websockets.md b/site/content/docs/multistep-checks/websockets.md
@@ -7,7 +7,7 @@ menu:
   resources:
     parent: "Multistep checks"
     identifier: "multistep-checks-websockets"
-cli: true
+
 ---
 
 To create a WebSocket check in Checkly, you'll need to write a script that establishes a WebSocket connection, sends messages, and validates responses.
-Original file line number
+Diff line change
@@ Expand Up / @@ -6,7 +6,7 @@ weight: 11 @@
     menu:
       resources:
         parent: "API checks"
-    cli: true
     ---
@@ Expand Down @@